Drezil/quarto
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fixups in formatting; minor other stuff.

Browse Source
This commit is contained in:
Nicole Dresselhaus
2025-06-29 13:46:55 +02:00
parent 2ba3c00de4
commit eb2d14ba98
13 changed files with 1186 additions and 1036 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
Coding/Haskell/FFPiH.md
View File

@ -7,6 +7,13 @@ categories:
- Haskell
date: 2018-01-01
title: Fortgeschrittene funktionale Programmierung in Haskell
format:
html:
other-links:
- text: FFPiH-Organisation auf Gitea
icon: cup-hot-fill
href: "https://gitea.dresselhaus.cloud/FFPiH"
rel: me
---
FFPiH ist eine Vorlesung, die ich zusammen mit einem Kommilitonen im Sommer 2015

4
Coding/Haskell/Webapp-Example/index.qmd
View File

@ -374,8 +374,6 @@ loggingMiddleware = liftIO $ mkRequestLogger $ def { outputFormat = CustomOutput
```
{{< dend >}}
#### Weitere Instanzen und Definitionen, die der Generator (noch) nicht macht
In der `Myservice.Types` werden ein paar hilfreiche Typen und Typ-Instanzen
@ -480,8 +478,6 @@ instance Out Response
instance FromBSON Repsonse -- FromBSON-Instanz geht immer davon aus, dass alle keys da sind (ggf. mit null bei Nothing).
```
{{< dend >}}
#### Was noch zu tun ist
Den Service implementieren. Einfach ein neues Modul aufmachen (z.B.

117
Writing/coding-age-ai.md
View File

@ -50,12 +50,12 @@ format:
## Introduction
In the fast eveolving field of AI there is a clear lack of reports on "what
In the fast evolving field of AI there is a clear lack of reports on "what
really works". Some techniques hailed as revolution (like the DeepSeek
Aha-Moment[@DeepSeek-AI2025DeepSeekR1IncentivizingReasoning]) for unlimited
potential were soon realized to "just" optimize nieche problems that can
potential were soon realized to "just" optimize niche problems that can
benchmarked[@Shao2025SpuriousRewardsRethinking]^[Like all decent humans i ain't
got time to read up on everything - so a big shoutout to
got time to read up on everything - so a big shoot-out to
[@bycloud2025LLMsRLRevelation] for doing thorough reviews on ML-topics and
linking the respective papers!].
@ -74,7 +74,7 @@ papers tested their finding on (qwen-series) also gets better with
RLVR-optimization if rewards are random instead of verified].
Therefore see this "Field Guide" for what it is: A current state of things that
work for at least 1 individuum in exactly this ecosystem at this point in time.
work for at least 1 Individuum in exactly this ecosystem at this point in time.
## How to program with Cursor
@ -83,7 +83,7 @@ In essence [Cursor](https://cursor.com) is "just" a fork of
functionality: Automatically injecting files into LLM-Prompts, offering
tool-aware LLMs to use [MCP](https://modelcontextprotocol.io/introduction)s,
read the filesystem, execute arbitrary commands in the shell (either
automomatically or after permission), getting feedback from the editor (i.e.
automatically or after permission), getting feedback from the editor (i.e.
installed linters, language-servers etc.) and thus have the same (or even
better) information/tools available as the programmer in front of the screen.
@ -97,10 +97,10 @@ they want - it can't be proven and (especially under US-Law) is not even
possible to resist lawful orders (including the gag-order to not talk about
these).
In practise one feels the direct pain points more severly. Some regular examples
include generating redundant code, because the current context was not aware of
utility-modules and functions it could use - leading to huge technical debt in
no time.
In practise one feels the direct pain points more severely. Some regular
examples include generating redundant code, because the current context was not
aware of utility-modules and functions it could use - leading to huge technical
debt in no time.
Therefore my preferred workflow is to "think bigger". Imagine being a product
owner of a huge, sluggish company. The left hand never knows what the right hand
@ -137,9 +137,9 @@ The main theme always follows a similar pattern:
what is _out of scope_.
- Pin the desired behaviour in a **Specification**.
Either this means changing currently established specifications (i.e.
bug/chang) or writing complete new ones (i.e. feature).
bug/change) or writing complete new ones (i.e. feature).
- Investigate **Spec-Compliance**.
Again the agentlooks at the codebase to identify _where_ things should change
Again the agent looks at the codebase to identify _where_ things should change
and _how_. Also recommendation are made on how it could achieve the goal.
- Generate **Tasks**.
From the compliance-report of spec-deviations (either from a bug or from a
@ -231,11 +231,27 @@ one‑sentence feature description plus any additional Q&A with the stakeholder.
### Output
• Create /tasks/<feature>/PRD.md • Markdown only – no prose, no code‑fences. •
File structure: # <Feature title> ## 1. Problem / Motivation ## 2. Goals ## 3.
Non‑Goals ## 4. Target Users & Personas ## 5. User Stories (Gherkin
“Given/When/Then”) ## 6. Acceptance Criteria ## 7. Technical Notes /
Dependencies ## 8. Open Questions
- Create /tasks/<feature>/PRD.md
- Markdown only – no prose, no code‑fences.
- File structure:
> # <Feature title>
>
> ## 1. Problem / Motivation
>
> ## 2. Goals
>
> ## 3. Non‑Goals
>
> ## 4. Target Users & Personas
>
> ## 5. User Stories (Gherkin “Given/When/Then”)
>
> ## 6. Acceptance Criteria
>
> ## 7. Technical Notes / Dependencies
>
> ## 8. Open Questions
### Process
@ -247,23 +263,26 @@ Dependencies ## 8. Open Questions
ask for further clarification up to 3 times following this schema, else flag
it in _Open Questions_.
4. After questions are answered reply exactly: Ready to generate the PRD.
5. On a user message that contains only the word "go" (case‑insensitive): •
Generate /tasks/<feature>/PRD.md following _Output_ spec. • Reply:
<feature>/PRD.md created – review it.
5. On a user message that contains only the word "go" (case‑insensitive):
- Generate /tasks/<feature>/PRD.md following _Output_ spec.
- Reply: <feature>/PRD.md created – review it.
6. STOP. Do **not** generate tasks or code in this rule.
### Writing guidelines
• Keep each bullet ≤120 characters. • Use action verbs and measurable language.
• Leave TBDs only in _Open Questions_. • No business fluff – pretend the reader
is a junior developer.
- Keep each bullet ≤120 characters.
- Use action verbs and measurable language.
- Leave TBDs only in _Open Questions_.
- No business fluff – pretend the reader is a junior developer.
### Safety rails
• Assume all work happens in a non‑production environment, unless otherwise
stated or requested by you. • Do not include sensitive data or credentials in
the PRD. • Check the generated Document with `markdownlint` (if available),
apply auto-fixes and fix the remaining issues manually.
- Assume all work happens in a non‑production environment, unless otherwise
stated or requested by you.
- Do not include sensitive data or credentials in the PRD.
- Check the generated Document with `markdownlint` (if available), apply
auto-fixes and fix the remaining issues manually.
```
:::
@ -305,19 +324,16 @@ Every specification should include:
```
2. **Scope and Boundaries**
- What is included/excluded
- Dependencies on other specifications
- Relationship to other components
3. **Detailed Requirements**
- Structured by logical sections
- Clear, unambiguous language
- Examples where helpful
4. **Error Handling**
- How errors should be handled
- Fallback behaviors
- Edge cases
@ -614,12 +630,13 @@ list that a junior developer (human or AI) can follow without extra context.
### Output
• Create /tasks/<feature>/TASKS.md (overwrite if it exists). • Markdown only, no
prose around it. • Epics = H2 headings (`## 1. <Epic>`). • Tasks = unchecked
check‑boxes (`- [ ] 1.1 <task>`). • Sub‑tasks = indent one space under their
parent (` - [ ] 1.1.1 <subtask>`). • Create a
/tasks/<feature>/Task*<Epic>*<task>\_<subtask>.md (i.e. `Task_3_2_4.md` for Epic
3, Task 2, Subtask 4)
- Create /tasks/<feature>/TASKS.md (overwrite if it exists).
- Markdown only, no prose around it.
- Epics = H2 headings (`## 1. <Epic>`).
- Tasks = unchecked check‑boxes (`- [ ] 1.1 <task>`).
- Sub‑tasks = indent one space under their parent (` - [ ] 1.1.1 <subtask>`).
- Create a /tasks/<feature>/Task*<Epic>*<task>\_<subtask>.md (i.e.
`Task_3_2_4.md` for Epic 3, Task 2, Subtask 4)
### Process
@ -644,20 +661,22 @@ parent (` - [ ] 1.1.1 <subtask>`). • Create a
### Writing guidelines
• Each item ≤120 characters, start with an action verb. • Hints are allowed
below each item as HTML-Comment and do not count against the 120 characters. •
Group related work into logical epics with ≤7 direct child items. • Prefer
concrete file paths, commands, specs or APIs when available. • Skip
implementation details obvious from the codebase in the overview. • If a task
only concerns up to 5 files, name them in the detailed file. Otherwise give
hints on how to search for them (i.e. "everything under src/models/").
- Each item ≤120 characters, start with an action verb.
- Hints are allowed below each item as HTML-Comment and do not count against the
120 characters.
- Group related work into logical epics with ≤7 direct child items.
- Prefer concrete file paths, commands, specs or APIs when available.
- Skip implementation details obvious from the codebase in the overview.
- If a task only concerns up to 5 files, name them in the detailed file.
Otherwise give hints on how to search for them (i.e. "everything under
`src/models/`").
### Safety rails
• Never touch production data. • Assume all work happens in a feature branch,
never commit directly to main. • Check the generated Document with
`markdownlint` (if available), apply auto-fixes and fix the remaining issues
manually.
- Never touch production data.
- Assume all work happens in a feature branch, never commit directly to main.
- Check the generated Document with `markdownlint` (if available), apply
auto-fixes and fix the remaining issues manually.
```
:::
@ -675,9 +694,9 @@ specialised coding-LLMs are enough to get the job done with this preparation.
## Example: Rules in Action
The codebase we look at here is a project called `gitlab_overviewer`. It takes
gitlab-api-keys and generates nice overviews for tracking metadata in different
GitLab-api-keys and generates nice overviews for tracking metadata in different
projects across different groups. With a nice export to markdown (for rendering
in gitlab itself) and quarto (for exporting to i.e. confluence) with multiple
in GitLab itself) and quarto (for exporting to i.e. confluence) with multiple
pages etc. pp.
The current issue is, that due to a complete rewrite we are happy with the
@ -1225,7 +1244,7 @@ this method works and _can_ yields great outcomes. Even small discrepancies in
the codebase tend to pop up during spec-reviews (which can be automated!). Next
up would be running those in some kind of CI-job and integrating tools like
issue-tracking into the agent instead of simple markdown-files in the repository
as makeshift issue-tracker. But not by me for the forseeable future, so if you
as makeshift issue-tracker. But not by me for the foreseeable future, so if you
are looking for a project, feel free!
**All in all this isn't a silver bullet for all AI-assisted development

2
dist/Coding/Haskell/FFPiH.html vendored
View File

@ -587,7 +587,7 @@ ul.task-list li input[type="checkbox"] {
<li><a href="#aufbau-der-vorlesung" id="toc-aufbau-der-vorlesung" class="nav-link active" data-scroll-target="#aufbau-der-vorlesung">Aufbau der Vorlesung</a></li>
<li><a href="#studentisches-feedback" id="toc-studentisches-feedback" class="nav-link" data-scroll-target="#studentisches-feedback">Studentisches Feedback</a></li>
</ul>
</nav>
<div class="quarto-other-links"><h2>Other Links</h2><ul><li><a href="https://gitea.dresselhaus.cloud/FFPiH" rel="me"><i class="bi bi-cup-hot-fill"></i>FFPiH-Organisation auf Gitea</a></li></ul></div></nav>
</div>
<!-- main -->
<main class="content" id="quarto-document-content">

2
dist/Coding/Haskell/Webapp-Example/index.html vendored
View File

@ -940,7 +940,6 @@ pre > code.sourceCode > span > a:first-child::before { text-decoration: underlin
<span id="cb8-179"><a href="#cb8-179" aria-hidden="true" tabindex="-1"></a> <span class="op">|</span> statusCode status <span class="op">&lt;</span> <span class="dv">300</span> <span class="ot">=</span> <span class="st">""</span></span>
<span id="cb8-180"><a href="#cb8-180" aria-hidden="true" tabindex="-1"></a> <span class="op">|</span> statusCode status <span class="op">&gt;</span> <span class="dv">399</span> <span class="op">&amp;&amp;</span> statusCode status <span class="op">&lt;</span> <span class="dv">500</span> <span class="ot">=</span> <span class="st">"Error code "</span><span class="op">&lt;&gt;</span>toLogStr (statusCode status) <span class="op">&lt;&gt;</span><span class="st">" sent. Request-Payload was: "</span><span class="op">&lt;&gt;</span> <span class="fu">mconcat</span> (toLogStr <span class="op">&lt;$&gt;</span> payload) <span class="op">&lt;&gt;</span> <span class="st">"\n"</span></span>
<span id="cb8-181"><a href="#cb8-181" aria-hidden="true" tabindex="-1"></a> <span class="op">|</span> <span class="fu">otherwise</span> <span class="ot">=</span> toLogStr (<span class="fu">show</span> r) <span class="op">&lt;&gt;</span> <span class="st">"\n"</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
{{&lt; dend &gt;}}
</blockquote></details></section>
<section id="weitere-instanzen-und-definitionen-die-der-generator-noch-nicht-macht" class="level4">
<h4 class="anchored" data-anchor-id="weitere-instanzen-und-definitionen-die-der-generator-noch-nicht-macht">Weitere Instanzen und Definitionen, die der Generator (noch) nicht macht</h4>
@ -1047,7 +1046,6 @@ pre > code.sourceCode > span > a:first-child::before { text-decoration: underlin
<span id="cb9-75"><a href="#cb9-75" aria-hidden="true" tabindex="-1"></a> </span>
<span id="cb9-76"><a href="#cb9-76" aria-hidden="true" tabindex="-1"></a><span class="kw">instance</span> <span class="dt">Out</span> <span class="dt">Response</span></span>
<span id="cb9-77"><a href="#cb9-77" aria-hidden="true" tabindex="-1"></a><span class="kw">instance</span> <span class="dt">FromBSON</span> <span class="dt">Repsonse</span> <span class="co">-- FromBSON-Instanz geht immer davon aus, dass alle keys da sind (ggf. mit null bei Nothing).</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
{{&lt; dend &gt;}}
</blockquote></details></section>
<section id="was-noch-zu-tun-ist" class="level4">
<h4 class="anchored" data-anchor-id="was-noch-zu-tun-ist">Was noch zu tun ist</h4>

421
dist/Writing/coding-age-ai.html vendored
View File

@ -739,17 +739,17 @@ div.csl-indent {
<section id="introduction" class="level2 page-columns page-full">
<h2 class="anchored" data-anchor-id="introduction">Introduction</h2>
<p>In the fast eveolving field of AI there is a clear lack of reports on “what really works”. Some techniques hailed as revolution (like the DeepSeek Aha-Moment<span class="citation" data-cites="DeepSeek-AI2025DeepSeekR1IncentivizingReasoning">[<a href="#ref-DeepSeek-AI2025DeepSeekR1IncentivizingReasoning" role="doc-biblioref">1</a>]</span>) for unlimited potential were soon realized to “just” optimize nieche problems that can benchmarked<span class="citation" data-cites="Shao2025SpuriousRewardsRethinking">[<a href="#ref-Shao2025SpuriousRewardsRethinking" role="doc-biblioref">2</a>]</span><a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>.</p>
<div class="no-row-height column-margin column-container"><div id="fn1"><p><sup>1</sup>&nbsp;Like all decent humans i ain’t got time to read up on everything - so a big shoutout to <span class="citation" data-cites="bycloud2025LLMsRLRevelation">[<a href="#ref-bycloud2025LLMsRLRevelation" role="doc-biblioref">3</a>]</span> for doing thorough reviews on ML-topics and linking the respective papers!</p></div><div id="fn2"><p><sup>2</sup>&nbsp;i.e.&nbsp;the “base model” nearly all papers tested their finding on (qwen-series) also gets better with RLVR-optimization if rewards are random instead of verified</p></div></div><p>I personally think it is an exercise in futility to get a <em>current</em> theoretical overview for forming a decent grounded opinion on the state of things. Even before one is done analyzing the literature, crossrefercencing and collecting evidence and then finally formulating methods and implementing them, the next revolution comes around that could put everything on its head again. In the afromentioned example the community went from “Reasoning is the solution” in January<span class="citation" data-cites="DeepSeek-AI2025DeepSeekR1IncentivizingReasoning">[<a href="#ref-DeepSeek-AI2025DeepSeekR1IncentivizingReasoning" role="doc-biblioref">1</a>]</span> over first critical views in March<span class="citation" data-cites="Liu2025UnderstandingR1ZeroLikeTraining">[<a href="#ref-Liu2025UnderstandingR1ZeroLikeTraining" role="doc-biblioref">4</a>]</span> to doubts on that claims validity of generating concepts previously not present in the base model in May<span class="citation" data-cites="Mukherjee2025ReinforcementLearningFinetunes">[<a href="#ref-Mukherjee2025ReinforcementLearningFinetunes" role="doc-biblioref">5</a>]</span> to complete ad-absurdum in June<span class="citation" data-cites="Shao2025SpuriousRewardsRethinking">[<a href="#ref-Shao2025SpuriousRewardsRethinking" role="doc-biblioref">2</a>]</span><a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a>.</p>
<p>Therefore see this “Field Guide” for what it is: A current state of things that work for at least 1 individuum in exactly this ecosystem at this point in time.</p>
<p>In the fast evolving field of AI there is a clear lack of reports on “what really works”. Some techniques hailed as revolution (like the DeepSeek Aha-Moment<span class="citation" data-cites="DeepSeek-AI2025DeepSeekR1IncentivizingReasoning">[<a href="#ref-DeepSeek-AI2025DeepSeekR1IncentivizingReasoning" role="doc-biblioref">1</a>]</span>) for unlimited potential were soon realized to “just” optimize niche problems that can benchmarked<span class="citation" data-cites="Shao2025SpuriousRewardsRethinking">[<a href="#ref-Shao2025SpuriousRewardsRethinking" role="doc-biblioref">2</a>]</span><a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>.</p>
<div class="no-row-height column-margin column-container"><div id="fn1"><p><sup>1</sup>&nbsp;Like all decent humans i ain’t got time to read up on everything - so a big shoot-out to <span class="citation" data-cites="bycloud2025LLMsRLRevelation">[<a href="#ref-bycloud2025LLMsRLRevelation" role="doc-biblioref">3</a>]</span> for doing thorough reviews on ML-topics and linking the respective papers!</p></div><div id="fn2"><p><sup>2</sup>&nbsp;i.e.&nbsp;the “base model” nearly all papers tested their finding on (qwen-series) also gets better with RLVR-optimization if rewards are random instead of verified</p></div></div><p>I personally think it is an exercise in futility to get a <em>current</em> theoretical overview for forming a decent grounded opinion on the state of things. Even before one is done analyzing the literature, crossrefercencing and collecting evidence and then finally formulating methods and implementing them, the next revolution comes around that could put everything on its head again. In the afromentioned example the community went from “Reasoning is the solution” in January<span class="citation" data-cites="DeepSeek-AI2025DeepSeekR1IncentivizingReasoning">[<a href="#ref-DeepSeek-AI2025DeepSeekR1IncentivizingReasoning" role="doc-biblioref">1</a>]</span> over first critical views in March<span class="citation" data-cites="Liu2025UnderstandingR1ZeroLikeTraining">[<a href="#ref-Liu2025UnderstandingR1ZeroLikeTraining" role="doc-biblioref">4</a>]</span> to doubts on that claims validity of generating concepts previously not present in the base model in May<span class="citation" data-cites="Mukherjee2025ReinforcementLearningFinetunes">[<a href="#ref-Mukherjee2025ReinforcementLearningFinetunes" role="doc-biblioref">5</a>]</span> to complete ad-absurdum in June<span class="citation" data-cites="Shao2025SpuriousRewardsRethinking">[<a href="#ref-Shao2025SpuriousRewardsRethinking" role="doc-biblioref">2</a>]</span><a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a>.</p>
<p>Therefore see this “Field Guide” for what it is: A current state of things that work for at least 1 Individuum in exactly this ecosystem at this point in time.</p>
</section>
<section id="how-to-program-with-cursor" class="level2">
<h2 class="anchored" data-anchor-id="how-to-program-with-cursor">How to program with Cursor</h2>
<p>In essence <a href="https://cursor.com">Cursor</a> is “just” a fork of <a href="https://code.visualstudio.com/">Microsofts VSCode</a> with some added functionality: Automatically injecting files into LLM-Prompts, offering tool-aware LLMs to use <a href="https://modelcontextprotocol.io/introduction">MCP</a>s, read the filesystem, execute arbitrary commands in the shell (either automomatically or after permission), getting feedback from the editor (i.e. installed linters, language-servers etc.) and thus have the same (or even better) information/tools available as the programmer in front of the screen.</p>
<p>In essence <a href="https://cursor.com">Cursor</a> is “just” a fork of <a href="https://code.visualstudio.com/">Microsofts VSCode</a> with some added functionality: Automatically injecting files into LLM-Prompts, offering tool-aware LLMs to use <a href="https://modelcontextprotocol.io/introduction">MCP</a>s, read the filesystem, execute arbitrary commands in the shell (either automatically or after permission), getting feedback from the editor (i.e. installed linters, language-servers etc.) and thus have the same (or even better) information/tools available as the programmer in front of the screen.</p>
<section id="capabilities-general-procedure" class="level3">
<h3 class="anchored" data-anchor-id="capabilities-general-procedure">Capabilities / General procedure</h3>
<p>The main issue is now: theoretically agentic IDEs can get all information - practically it is limited directly by token-window sizes, costs of these queries; and indirectly by outsourced costs like environmental impacts, data-security, etc. The suppliers of such services can claim privacy as much as they want - it can’t be proven and (especially under US-Law) is not even possible to resist lawful orders (including the gag-order to not talk about these).</p>
<p>In practise one feels the direct pain points more severly. Some regular examples include generating redundant code, because the current context was not aware of utility-modules and functions it could use - leading to huge technical debt in no time.</p>
<p>In practise one feels the direct pain points more severely. Some regular examples include generating redundant code, because the current context was not aware of utility-modules and functions it could use - leading to huge technical debt in no time.</p>
<p>Therefore my preferred workflow is to “think bigger”. Imagine being a product owner of a huge, sluggish company. The left hand never knows what the right hand does or has done (i.e.&nbsp;the LLM forgetting things already exist in the codebase), everything has to be rigorous defined, specified and enforced. Some people reported good results with Test-Driven-Development (TDD) - but in my experience these things only prevent regressions and not proactively enforce the desired agent behaviour.</p>
</section>
<section id="lessons-from-project-management" class="level3">
@ -764,9 +764,9 @@ This could be a bug, a feature, some changes to existing behaviour etc.</li>
This dives into the codebase to asses the current state of things. Maybe some bugs are obvious and easily fixed.<br>
This formalizes that the LLM understood what <em>should</em> be done and especially what is <em>out of scope</em>.</li>
<li>Pin the desired behaviour in a <strong>Specification</strong>.<br>
Either this means changing currently established specifications (i.e. bug/chang) or writing complete new ones (i.e.&nbsp;feature).</li>
Either this means changing currently established specifications (i.e. bug/change) or writing complete new ones (i.e.&nbsp;feature).</li>
<li>Investigate <strong>Spec-Compliance</strong>.<br>
Again the agentlooks at the codebase to identify <em>where</em> things should change and <em>how</em>. Also recommendation are made on how it could achieve the goal.</li>
Again the agent looks at the codebase to identify <em>where</em> things should change and <em>how</em>. Also recommendation are made on how it could achieve the goal.</li>
<li>Generate <strong>Tasks</strong>.<br>
From the compliance-report of spec-deviations (either from a bug or from a new/changed spec) finally a Plan to fix everything can be derived (think: Sprint-Planning).</li>
<li><strong>NOTE: Up to here the agent never touched the code.</strong></li>
@ -839,39 +839,58 @@ This is most often the most trivial step. Everything is known and formulated for
<span id="cb2-13"><a href="#cb2-13" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-14"><a href="#cb2-14" aria-hidden="true" tabindex="-1"></a><span class="fu">### Output</span></span>
<span id="cb2-15"><a href="#cb2-15" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-16"><a href="#cb2-16" aria-hidden="true" tabindex="-1"></a>• Create /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/PRD.md • Markdown only – no prose, no code‑fences. •</span>
<span id="cb2-17"><a href="#cb2-17" aria-hidden="true" tabindex="-1"></a>File structure: # <span class="dt">&lt;</span><span class="kw">Feature</span><span class="ot"> title</span><span class="dt">&gt;</span> ## 1. Problem / Motivation ## 2. Goals ## 3.</span>
<span id="cb2-18"><a href="#cb2-18" aria-hidden="true" tabindex="-1"></a>Non‑Goals ## 4. Target Users &amp; Personas ## 5. User Stories (Gherkin</span>
<span id="cb2-19"><a href="#cb2-19" aria-hidden="true" tabindex="-1"></a>“Given/When/Then”) ## 6. Acceptance Criteria ## 7. Technical Notes /</span>
<span id="cb2-20"><a href="#cb2-20" aria-hidden="true" tabindex="-1"></a>Dependencies ## 8. Open Questions</span>
<span id="cb2-21"><a href="#cb2-21" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-22"><a href="#cb2-22" aria-hidden="true" tabindex="-1"></a><span class="fu">### Process</span></span>
<span id="cb2-23"><a href="#cb2-23" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-24"><a href="#cb2-24" aria-hidden="true" tabindex="-1"></a><span class="ss">1. </span>Stakeholder provides a single‑sentence feature idea and invokes this rule.</span>
<span id="cb2-25"><a href="#cb2-25" aria-hidden="true" tabindex="-1"></a><span class="ss">2. </span>Look at specifications in <span class="in">`specs/`</span> and inspect the code if needed to get an</span>
<span id="cb2-26"><a href="#cb2-26" aria-hidden="true" tabindex="-1"></a> idea what the Stakeholder expects from this feature.</span>
<span id="cb2-27"><a href="#cb2-27" aria-hidden="true" tabindex="-1"></a><span class="ss">3. </span>Ask up to five clarifying questions (Q1 … Q5). If anything is still vague</span>
<span id="cb2-28"><a href="#cb2-28" aria-hidden="true" tabindex="-1"></a> after five, look into the project with the new information provided. You may</span>
<span id="cb2-29"><a href="#cb2-29" aria-hidden="true" tabindex="-1"></a> ask for further clarification up to 3 times following this schema, else flag</span>
<span id="cb2-30"><a href="#cb2-30" aria-hidden="true" tabindex="-1"></a> it in _Open Questions_.</span>
<span id="cb2-31"><a href="#cb2-31" aria-hidden="true" tabindex="-1"></a><span class="ss">4. </span>After questions are answered reply exactly: Ready to generate the PRD.</span>
<span id="cb2-32"><a href="#cb2-32" aria-hidden="true" tabindex="-1"></a><span class="ss">5. </span>On a user message that contains only the word "go" (case‑insensitive): •</span>
<span id="cb2-33"><a href="#cb2-33" aria-hidden="true" tabindex="-1"></a> Generate /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/PRD.md following _Output_ spec. • Reply:</span>
<span id="cb2-34"><a href="#cb2-34" aria-hidden="true" tabindex="-1"></a> <span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/PRD.md created – review it.</span>
<span id="cb2-35"><a href="#cb2-35" aria-hidden="true" tabindex="-1"></a><span class="ss">6. </span>STOP. Do **not** generate tasks or code in this rule.</span>
<span id="cb2-36"><a href="#cb2-36" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-37"><a href="#cb2-37" aria-hidden="true" tabindex="-1"></a><span class="fu">### Writing guidelines</span></span>
<span id="cb2-38"><a href="#cb2-38" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-39"><a href="#cb2-39" aria-hidden="true" tabindex="-1"></a>• Keep each bullet ≤120 characters. • Use action verbs and measurable language.</span>
<span id="cb2-40"><a href="#cb2-40" aria-hidden="true" tabindex="-1"></a>• Leave TBDs only in _Open Questions_. • No business fluff – pretend the reader</span>
<span id="cb2-41"><a href="#cb2-41" aria-hidden="true" tabindex="-1"></a>is a junior developer.</span>
<span id="cb2-42"><a href="#cb2-42" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-43"><a href="#cb2-43" aria-hidden="true" tabindex="-1"></a><span class="fu">### Safety rails</span></span>
<span id="cb2-44"><a href="#cb2-44" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-45"><a href="#cb2-45" aria-hidden="true" tabindex="-1"></a>• Assume all work happens in a non‑production environment, unless otherwise</span>
<span id="cb2-46"><a href="#cb2-46" aria-hidden="true" tabindex="-1"></a>stated or requested by you. • Do not include sensitive data or credentials in</span>
<span id="cb2-47"><a href="#cb2-47" aria-hidden="true" tabindex="-1"></a>the PRD. • Check the generated Document with <span class="in">`markdownlint`</span> (if available),</span>
<span id="cb2-48"><a href="#cb2-48" aria-hidden="true" tabindex="-1"></a>apply auto-fixes and fix the remaining issues manually.</span></code><button title="In die Zwischenablage kopieren" class="code-copy-button"><i class="bi"></i></button></pre></div>
<span id="cb2-16"><a href="#cb2-16" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Create /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/PRD.md</span>
<span id="cb2-17"><a href="#cb2-17" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Markdown only – no prose, no code‑fences.</span>
<span id="cb2-18"><a href="#cb2-18" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>File structure:</span>
<span id="cb2-19"><a href="#cb2-19" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-20"><a href="#cb2-20" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; # </span><span class="dt">&lt;</span><span class="kw">Feature</span><span class="ot"> title</span><span class="dt">&gt;</span></span>
<span id="cb2-21"><a href="#cb2-21" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt;</span></span>
<span id="cb2-22"><a href="#cb2-22" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; ## 1. Problem / Motivation</span></span>
<span id="cb2-23"><a href="#cb2-23" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt;</span></span>
<span id="cb2-24"><a href="#cb2-24" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; ## 2. Goals</span></span>
<span id="cb2-25"><a href="#cb2-25" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt;</span></span>
<span id="cb2-26"><a href="#cb2-26" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; ## 3. Non‑Goals</span></span>
<span id="cb2-27"><a href="#cb2-27" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt;</span></span>
<span id="cb2-28"><a href="#cb2-28" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; ## 4. Target Users &amp; Personas</span></span>
<span id="cb2-29"><a href="#cb2-29" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt;</span></span>
<span id="cb2-30"><a href="#cb2-30" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; ## 5. User Stories (Gherkin “Given/When/Then”)</span></span>
<span id="cb2-31"><a href="#cb2-31" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt;</span></span>
<span id="cb2-32"><a href="#cb2-32" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; ## 6. Acceptance Criteria</span></span>
<span id="cb2-33"><a href="#cb2-33" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt;</span></span>
<span id="cb2-34"><a href="#cb2-34" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; ## 7. Technical Notes / Dependencies</span></span>
<span id="cb2-35"><a href="#cb2-35" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt;</span></span>
<span id="cb2-36"><a href="#cb2-36" aria-hidden="true" tabindex="-1"></a><span class="at"> &gt; ## 8. Open Questions</span></span>
<span id="cb2-37"><a href="#cb2-37" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-38"><a href="#cb2-38" aria-hidden="true" tabindex="-1"></a><span class="fu">### Process</span></span>
<span id="cb2-39"><a href="#cb2-39" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-40"><a href="#cb2-40" aria-hidden="true" tabindex="-1"></a><span class="ss">1. </span>Stakeholder provides a single‑sentence feature idea and invokes this rule.</span>
<span id="cb2-41"><a href="#cb2-41" aria-hidden="true" tabindex="-1"></a><span class="ss">2. </span>Look at specifications in <span class="in">`specs/`</span> and inspect the code if needed to get an</span>
<span id="cb2-42"><a href="#cb2-42" aria-hidden="true" tabindex="-1"></a> idea what the Stakeholder expects from this feature.</span>
<span id="cb2-43"><a href="#cb2-43" aria-hidden="true" tabindex="-1"></a><span class="ss">3. </span>Ask up to five clarifying questions (Q1 … Q5). If anything is still vague</span>
<span id="cb2-44"><a href="#cb2-44" aria-hidden="true" tabindex="-1"></a> after five, look into the project with the new information provided. You may</span>
<span id="cb2-45"><a href="#cb2-45" aria-hidden="true" tabindex="-1"></a> ask for further clarification up to 3 times following this schema, else flag</span>
<span id="cb2-46"><a href="#cb2-46" aria-hidden="true" tabindex="-1"></a> it in _Open Questions_.</span>
<span id="cb2-47"><a href="#cb2-47" aria-hidden="true" tabindex="-1"></a><span class="ss">4. </span>After questions are answered reply exactly: Ready to generate the PRD.</span>
<span id="cb2-48"><a href="#cb2-48" aria-hidden="true" tabindex="-1"></a><span class="ss">5. </span>On a user message that contains only the word "go" (case‑insensitive):</span>
<span id="cb2-49"><a href="#cb2-49" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Generate /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/PRD.md following _Output_ spec.</span>
<span id="cb2-50"><a href="#cb2-50" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Reply: <span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/PRD.md created – review it.</span>
<span id="cb2-51"><a href="#cb2-51" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-52"><a href="#cb2-52" aria-hidden="true" tabindex="-1"></a><span class="ss">6. </span>STOP. Do **not** generate tasks or code in this rule.</span>
<span id="cb2-53"><a href="#cb2-53" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-54"><a href="#cb2-54" aria-hidden="true" tabindex="-1"></a><span class="fu">### Writing guidelines</span></span>
<span id="cb2-55"><a href="#cb2-55" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-56"><a href="#cb2-56" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Keep each bullet ≤120 characters.</span>
<span id="cb2-57"><a href="#cb2-57" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Use action verbs and measurable language.</span>
<span id="cb2-58"><a href="#cb2-58" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Leave TBDs only in _Open Questions_.</span>
<span id="cb2-59"><a href="#cb2-59" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>No business fluff – pretend the reader is a junior developer.</span>
<span id="cb2-60"><a href="#cb2-60" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-61"><a href="#cb2-61" aria-hidden="true" tabindex="-1"></a><span class="fu">### Safety rails</span></span>
<span id="cb2-62"><a href="#cb2-62" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-63"><a href="#cb2-63" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Assume all work happens in a non‑production environment, unless otherwise</span>
<span id="cb2-64"><a href="#cb2-64" aria-hidden="true" tabindex="-1"></a> stated or requested by you.</span>
<span id="cb2-65"><a href="#cb2-65" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Do not include sensitive data or credentials in the PRD.</span>
<span id="cb2-66"><a href="#cb2-66" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Check the generated Document with <span class="in">`markdownlint`</span> (if available), apply</span>
<span id="cb2-67"><a href="#cb2-67" aria-hidden="true" tabindex="-1"></a> auto-fixes and fix the remaining issues manually.</span></code><button title="In die Zwischenablage kopieren" class="code-copy-button"><i class="bi"></i></button></pre></div>
</div>
<p>A call to this rule usually looks like <code>@generate-prd We noticed, that …. Therefore investigate the codebase to come up with a PRD addressing these issues.</code>.</p>
</section>
@ -907,121 +926,118 @@ This is most often the most trivial step. Everything is known and formulated for
<span id="cb3-27"><a href="#cb3-27" aria-hidden="true" tabindex="-1"></a> <span class="in">```</span></span>
<span id="cb3-28"><a href="#cb3-28" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-29"><a href="#cb3-29" aria-hidden="true" tabindex="-1"></a><span class="ss">2. </span>**Scope and Boundaries**</span>
<span id="cb3-30"><a href="#cb3-30" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-31"><a href="#cb3-31" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>What is included/excluded</span>
<span id="cb3-32"><a href="#cb3-32" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Dependencies on other specifications</span>
<span id="cb3-33"><a href="#cb3-33" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Relationship to other components</span>
<span id="cb3-34"><a href="#cb3-34" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-35"><a href="#cb3-35" aria-hidden="true" tabindex="-1"></a><span class="ss">3. </span>**Detailed Requirements**</span>
<span id="cb3-36"><a href="#cb3-36" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-37"><a href="#cb3-37" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Structured by logical sections</span>
<span id="cb3-38"><a href="#cb3-38" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Clear, unambiguous language</span>
<span id="cb3-39"><a href="#cb3-39" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Examples where helpful</span>
<span id="cb3-40"><a href="#cb3-40" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-41"><a href="#cb3-41" aria-hidden="true" tabindex="-1"></a><span class="ss">4. </span>**Error Handling**</span>
<span id="cb3-42"><a href="#cb3-42" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-43"><a href="#cb3-43" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>How errors should be handled</span>
<span id="cb3-44"><a href="#cb3-44" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Fallback behaviors</span>
<span id="cb3-45"><a href="#cb3-45" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Edge cases</span>
<span id="cb3-46"><a href="#cb3-46" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-47"><a href="#cb3-47" aria-hidden="true" tabindex="-1"></a><span class="ss">5. </span>**Testing Requirements**</span>
<span id="cb3-48"><a href="#cb3-48" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Expected test coverage</span>
<span id="cb3-49"><a href="#cb3-49" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Snapshot requirements</span>
<span id="cb3-50"><a href="#cb3-50" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Approval test criteria</span>
<span id="cb3-51"><a href="#cb3-51" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-52"><a href="#cb3-52" aria-hidden="true" tabindex="-1"></a><span class="fu">## Writing Standards</span></span>
<span id="cb3-53"><a href="#cb3-53" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-54"><a href="#cb3-54" aria-hidden="true" tabindex="-1"></a><span class="fu">### Clarity and Precision</span></span>
<span id="cb3-55"><a href="#cb3-55" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-56"><a href="#cb3-56" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Use specific language**: Avoid vague terms like "should" or "might"</span>
<span id="cb3-57"><a href="#cb3-57" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Provide examples**: Include concrete examples for complex requirements</span>
<span id="cb3-58"><a href="#cb3-58" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Define terms**: Clearly define any technical terms or concepts</span>
<span id="cb3-59"><a href="#cb3-59" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Use consistent formatting**: Follow established patterns from existing specs</span>
<span id="cb3-60"><a href="#cb3-60" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-61"><a href="#cb3-61" aria-hidden="true" tabindex="-1"></a><span class="fu">### Structure and Organization</span></span>
<span id="cb3-62"><a href="#cb3-62" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-63"><a href="#cb3-63" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Logical flow**: Organize sections in logical order</span>
<span id="cb3-64"><a href="#cb3-64" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Consistent headings**: Use consistent heading levels and naming</span>
<span id="cb3-65"><a href="#cb3-65" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Cross-references**: Link to related specifications using</span>
<span id="cb3-66"><a href="#cb3-66" aria-hidden="true" tabindex="-1"></a> <span class="in">`[spec_name](mdc:specs/spec_name.md)`</span></span>
<span id="cb3-67"><a href="#cb3-67" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Code blocks**: Use appropriate language tags for code examples</span>
<span id="cb3-68"><a href="#cb3-68" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-69"><a href="#cb3-69" aria-hidden="true" tabindex="-1"></a><span class="fu">### Completeness</span></span>
<span id="cb3-70"><a href="#cb3-70" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-71"><a href="#cb3-71" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Cover all cases**: Address normal, error, and edge cases</span>
<span id="cb3-72"><a href="#cb3-72" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Be exhaustive**: Don't assume implementation details</span>
<span id="cb3-73"><a href="#cb3-73" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Consider interactions**: How this spec relates to others</span>
<span id="cb3-74"><a href="#cb3-74" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Future-proof**: Consider potential changes and extensions</span>
<span id="cb3-75"><a href="#cb3-75" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-76"><a href="#cb3-76" aria-hidden="true" tabindex="-1"></a><span class="fu">## Specification Maintenance</span></span>
<span id="cb3-77"><a href="#cb3-77" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-78"><a href="#cb3-78" aria-hidden="true" tabindex="-1"></a><span class="fu">### Version Control</span></span>
<span id="cb3-79"><a href="#cb3-79" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-80"><a href="#cb3-80" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Update specs first**: When changing behavior, update spec before</span>
<span id="cb3-81"><a href="#cb3-81" aria-hidden="true" tabindex="-1"></a> implementation</span>
<span id="cb3-82"><a href="#cb3-82" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Document changes**: Use clear commit messages explaining spec changes</span>
<span id="cb3-83"><a href="#cb3-83" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Review process**: Have specs reviewed before implementation</span>
<span id="cb3-84"><a href="#cb3-84" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-85"><a href="#cb3-85" aria-hidden="true" tabindex="-1"></a><span class="fu">### Consistency Checks</span></span>
<span id="cb3-86"><a href="#cb3-86" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-87"><a href="#cb3-87" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Cross-reference validation**: Ensure all links to other specs are valid</span>
<span id="cb3-88"><a href="#cb3-88" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Terminology consistency**: Use consistent terms across all specs</span>
<span id="cb3-89"><a href="#cb3-89" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Format consistency**: Follow established formatting patterns</span>
<span id="cb3-90"><a href="#cb3-90" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-91"><a href="#cb3-91" aria-hidden="true" tabindex="-1"></a><span class="fu">### Testing Integration</span></span>
<span id="cb3-92"><a href="#cb3-92" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-93"><a href="#cb3-93" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Spec-driven tests**: Write tests based on specification requirements</span>
<span id="cb3-94"><a href="#cb3-94" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Snapshot validation**: Ensure snapshots match specification exactly</span>
<span id="cb3-95"><a href="#cb3-95" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Approval tests**: Use approval tests to catch spec violations</span>
<span id="cb3-96"><a href="#cb3-96" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-97"><a href="#cb3-97" aria-hidden="true" tabindex="-1"></a><span class="fu">## Quality Checklist</span></span>
<span id="cb3-98"><a href="#cb3-98" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-99"><a href="#cb3-99" aria-hidden="true" tabindex="-1"></a><span class="fu">### Before Finalizing Specification</span></span>
<span id="cb3-100"><a href="#cb3-100" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-101"><a href="#cb3-101" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> All requirements clearly stated</span>
<span id="cb3-102"><a href="#cb3-102" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Examples provided for complex requirements</span>
<span id="cb3-103"><a href="#cb3-103" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Error cases covered</span>
<span id="cb3-104"><a href="#cb3-104" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Cross-references to other specs included</span>
<span id="cb3-105"><a href="#cb3-105" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Out of scope items clearly defined</span>
<span id="cb3-106"><a href="#cb3-106" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Testing requirements specified</span>
<span id="cb3-107"><a href="#cb3-107" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Consistent formatting throughout</span>
<span id="cb3-108"><a href="#cb3-108" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Check the generated Document with <span class="in">`markdownlint`</span> (if available), apply</span>
<span id="cb3-109"><a href="#cb3-109" aria-hidden="true" tabindex="-1"></a> auto-fixes and fix the remaining issues manually.</span>
<span id="cb3-110"><a href="#cb3-110" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-111"><a href="#cb3-111" aria-hidden="true" tabindex="-1"></a><span class="fu">### Review Criteria</span></span>
<span id="cb3-112"><a href="#cb3-112" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-113"><a href="#cb3-113" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Is the specification unambiguous?</span>
<span id="cb3-114"><a href="#cb3-114" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Are all edge cases covered?</span>
<span id="cb3-115"><a href="#cb3-115" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Does it integrate well with other specs?</span>
<span id="cb3-116"><a href="#cb3-116" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Is it testable?</span>
<span id="cb3-117"><a href="#cb3-117" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Is it maintainable?</span>
<span id="cb3-118"><a href="#cb3-118" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-119"><a href="#cb3-119" aria-hidden="true" tabindex="-1"></a><span class="fu">## Common Pitfalls to Avoid</span></span>
<span id="cb3-120"><a href="#cb3-120" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-121"><a href="#cb3-121" aria-hidden="true" tabindex="-1"></a><span class="fu">### Ambiguity</span></span>
<span id="cb3-122"><a href="#cb3-122" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-123"><a href="#cb3-123" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Vague language**: "The system should handle errors gracefully"</span>
<span id="cb3-124"><a href="#cb3-124" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Missing details**: Not specifying exact error handling behavior</span>
<span id="cb3-125"><a href="#cb3-125" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Unclear relationships**: Not explaining how components interact</span>
<span id="cb3-126"><a href="#cb3-126" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-127"><a href="#cb3-127" aria-hidden="true" tabindex="-1"></a><span class="fu">### Inconsistency</span></span>
<span id="cb3-128"><a href="#cb3-128" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-129"><a href="#cb3-129" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Different terms**: Using different terms for the same concept</span>
<span id="cb3-130"><a href="#cb3-130" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Inconsistent formatting**: Not following established patterns</span>
<span id="cb3-131"><a href="#cb3-131" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Conflicting requirements**: Requirements that contradict other specs</span>
<span id="cb3-132"><a href="#cb3-132" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-133"><a href="#cb3-133" aria-hidden="true" tabindex="-1"></a><span class="fu">### Incompleteness</span></span>
<span id="cb3-134"><a href="#cb3-134" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-135"><a href="#cb3-135" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Missing edge cases**: Not considering unusual scenarios</span>
<span id="cb3-136"><a href="#cb3-136" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Incomplete examples**: Examples that don't cover all cases</span>
<span id="cb3-137"><a href="#cb3-137" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Missing error handling**: Not specifying what happens when things go wrong</span>
<span id="cb3-138"><a href="#cb3-138" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-139"><a href="#cb3-139" aria-hidden="true" tabindex="-1"></a><span class="fu">## Related Rules</span></span>
<span id="cb3-140"><a href="#cb3-140" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-141"><a href="#cb3-141" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="co">[</span><span class="ot">spec-compliance-investigation.mdc</span><span class="co">](mdc:.cursor/rules/spec-compliance-investigation.mdc)</span></span>
<span id="cb3-142"><a href="#cb3-142" aria-hidden="true" tabindex="-1"></a> How to investigate spec-implementation discrepancies</span>
<span id="cb3-143"><a href="#cb3-143" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="co">[</span><span class="ot">base_overview.mdc</span><span class="co">](mdc:.cursor/rules/base_overview.mdc)</span> Project structure and</span>
<span id="cb3-144"><a href="#cb3-144" aria-hidden="true" tabindex="-1"></a> conventions</span></code><button title="In die Zwischenablage kopieren" class="code-copy-button"><i class="bi"></i></button></pre></div>
<span id="cb3-30"><a href="#cb3-30" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>What is included/excluded</span>
<span id="cb3-31"><a href="#cb3-31" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Dependencies on other specifications</span>
<span id="cb3-32"><a href="#cb3-32" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Relationship to other components</span>
<span id="cb3-33"><a href="#cb3-33" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-34"><a href="#cb3-34" aria-hidden="true" tabindex="-1"></a><span class="ss">3. </span>**Detailed Requirements**</span>
<span id="cb3-35"><a href="#cb3-35" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Structured by logical sections</span>
<span id="cb3-36"><a href="#cb3-36" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Clear, unambiguous language</span>
<span id="cb3-37"><a href="#cb3-37" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Examples where helpful</span>
<span id="cb3-38"><a href="#cb3-38" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-39"><a href="#cb3-39" aria-hidden="true" tabindex="-1"></a><span class="ss">4. </span>**Error Handling**</span>
<span id="cb3-40"><a href="#cb3-40" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>How errors should be handled</span>
<span id="cb3-41"><a href="#cb3-41" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Fallback behaviors</span>
<span id="cb3-42"><a href="#cb3-42" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Edge cases</span>
<span id="cb3-43"><a href="#cb3-43" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-44"><a href="#cb3-44" aria-hidden="true" tabindex="-1"></a><span class="ss">5. </span>**Testing Requirements**</span>
<span id="cb3-45"><a href="#cb3-45" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Expected test coverage</span>
<span id="cb3-46"><a href="#cb3-46" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Snapshot requirements</span>
<span id="cb3-47"><a href="#cb3-47" aria-hidden="true" tabindex="-1"></a><span class="ss"> - </span>Approval test criteria</span>
<span id="cb3-48"><a href="#cb3-48" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-49"><a href="#cb3-49" aria-hidden="true" tabindex="-1"></a><span class="fu">## Writing Standards</span></span>
<span id="cb3-50"><a href="#cb3-50" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-51"><a href="#cb3-51" aria-hidden="true" tabindex="-1"></a><span class="fu">### Clarity and Precision</span></span>
<span id="cb3-52"><a href="#cb3-52" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-53"><a href="#cb3-53" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Use specific language**: Avoid vague terms like "should" or "might"</span>
<span id="cb3-54"><a href="#cb3-54" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Provide examples**: Include concrete examples for complex requirements</span>
<span id="cb3-55"><a href="#cb3-55" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Define terms**: Clearly define any technical terms or concepts</span>
<span id="cb3-56"><a href="#cb3-56" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Use consistent formatting**: Follow established patterns from existing specs</span>
<span id="cb3-57"><a href="#cb3-57" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-58"><a href="#cb3-58" aria-hidden="true" tabindex="-1"></a><span class="fu">### Structure and Organization</span></span>
<span id="cb3-59"><a href="#cb3-59" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-60"><a href="#cb3-60" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Logical flow**: Organize sections in logical order</span>
<span id="cb3-61"><a href="#cb3-61" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Consistent headings**: Use consistent heading levels and naming</span>
<span id="cb3-62"><a href="#cb3-62" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Cross-references**: Link to related specifications using</span>
<span id="cb3-63"><a href="#cb3-63" aria-hidden="true" tabindex="-1"></a> <span class="in">`[spec_name](mdc:specs/spec_name.md)`</span></span>
<span id="cb3-64"><a href="#cb3-64" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Code blocks**: Use appropriate language tags for code examples</span>
<span id="cb3-65"><a href="#cb3-65" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-66"><a href="#cb3-66" aria-hidden="true" tabindex="-1"></a><span class="fu">### Completeness</span></span>
<span id="cb3-67"><a href="#cb3-67" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-68"><a href="#cb3-68" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Cover all cases**: Address normal, error, and edge cases</span>
<span id="cb3-69"><a href="#cb3-69" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Be exhaustive**: Don't assume implementation details</span>
<span id="cb3-70"><a href="#cb3-70" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Consider interactions**: How this spec relates to others</span>
<span id="cb3-71"><a href="#cb3-71" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Future-proof**: Consider potential changes and extensions</span>
<span id="cb3-72"><a href="#cb3-72" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-73"><a href="#cb3-73" aria-hidden="true" tabindex="-1"></a><span class="fu">## Specification Maintenance</span></span>
<span id="cb3-74"><a href="#cb3-74" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-75"><a href="#cb3-75" aria-hidden="true" tabindex="-1"></a><span class="fu">### Version Control</span></span>
<span id="cb3-76"><a href="#cb3-76" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-77"><a href="#cb3-77" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Update specs first**: When changing behavior, update spec before</span>
<span id="cb3-78"><a href="#cb3-78" aria-hidden="true" tabindex="-1"></a> implementation</span>
<span id="cb3-79"><a href="#cb3-79" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Document changes**: Use clear commit messages explaining spec changes</span>
<span id="cb3-80"><a href="#cb3-80" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Review process**: Have specs reviewed before implementation</span>
<span id="cb3-81"><a href="#cb3-81" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-82"><a href="#cb3-82" aria-hidden="true" tabindex="-1"></a><span class="fu">### Consistency Checks</span></span>
<span id="cb3-83"><a href="#cb3-83" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-84"><a href="#cb3-84" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Cross-reference validation**: Ensure all links to other specs are valid</span>
<span id="cb3-85"><a href="#cb3-85" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Terminology consistency**: Use consistent terms across all specs</span>
<span id="cb3-86"><a href="#cb3-86" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Format consistency**: Follow established formatting patterns</span>
<span id="cb3-87"><a href="#cb3-87" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-88"><a href="#cb3-88" aria-hidden="true" tabindex="-1"></a><span class="fu">### Testing Integration</span></span>
<span id="cb3-89"><a href="#cb3-89" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-90"><a href="#cb3-90" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Spec-driven tests**: Write tests based on specification requirements</span>
<span id="cb3-91"><a href="#cb3-91" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Snapshot validation**: Ensure snapshots match specification exactly</span>
<span id="cb3-92"><a href="#cb3-92" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Approval tests**: Use approval tests to catch spec violations</span>
<span id="cb3-93"><a href="#cb3-93" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-94"><a href="#cb3-94" aria-hidden="true" tabindex="-1"></a><span class="fu">## Quality Checklist</span></span>
<span id="cb3-95"><a href="#cb3-95" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-96"><a href="#cb3-96" aria-hidden="true" tabindex="-1"></a><span class="fu">### Before Finalizing Specification</span></span>
<span id="cb3-97"><a href="#cb3-97" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-98"><a href="#cb3-98" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> All requirements clearly stated</span>
<span id="cb3-99"><a href="#cb3-99" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Examples provided for complex requirements</span>
<span id="cb3-100"><a href="#cb3-100" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Error cases covered</span>
<span id="cb3-101"><a href="#cb3-101" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Cross-references to other specs included</span>
<span id="cb3-102"><a href="#cb3-102" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Out of scope items clearly defined</span>
<span id="cb3-103"><a href="#cb3-103" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Testing requirements specified</span>
<span id="cb3-104"><a href="#cb3-104" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Consistent formatting throughout</span>
<span id="cb3-105"><a href="#cb3-105" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Check the generated Document with <span class="in">`markdownlint`</span> (if available), apply</span>
<span id="cb3-106"><a href="#cb3-106" aria-hidden="true" tabindex="-1"></a> auto-fixes and fix the remaining issues manually.</span>
<span id="cb3-107"><a href="#cb3-107" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-108"><a href="#cb3-108" aria-hidden="true" tabindex="-1"></a><span class="fu">### Review Criteria</span></span>
<span id="cb3-109"><a href="#cb3-109" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-110"><a href="#cb3-110" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Is the specification unambiguous?</span>
<span id="cb3-111"><a href="#cb3-111" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Are all edge cases covered?</span>
<span id="cb3-112"><a href="#cb3-112" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Does it integrate well with other specs?</span>
<span id="cb3-113"><a href="#cb3-113" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Is it testable?</span>
<span id="cb3-114"><a href="#cb3-114" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="va">[ ]</span> Is it maintainable?</span>
<span id="cb3-115"><a href="#cb3-115" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-116"><a href="#cb3-116" aria-hidden="true" tabindex="-1"></a><span class="fu">## Common Pitfalls to Avoid</span></span>
<span id="cb3-117"><a href="#cb3-117" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-118"><a href="#cb3-118" aria-hidden="true" tabindex="-1"></a><span class="fu">### Ambiguity</span></span>
<span id="cb3-119"><a href="#cb3-119" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-120"><a href="#cb3-120" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Vague language**: "The system should handle errors gracefully"</span>
<span id="cb3-121"><a href="#cb3-121" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Missing details**: Not specifying exact error handling behavior</span>
<span id="cb3-122"><a href="#cb3-122" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Unclear relationships**: Not explaining how components interact</span>
<span id="cb3-123"><a href="#cb3-123" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-124"><a href="#cb3-124" aria-hidden="true" tabindex="-1"></a><span class="fu">### Inconsistency</span></span>
<span id="cb3-125"><a href="#cb3-125" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-126"><a href="#cb3-126" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Different terms**: Using different terms for the same concept</span>
<span id="cb3-127"><a href="#cb3-127" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Inconsistent formatting**: Not following established patterns</span>
<span id="cb3-128"><a href="#cb3-128" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Conflicting requirements**: Requirements that contradict other specs</span>
<span id="cb3-129"><a href="#cb3-129" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-130"><a href="#cb3-130" aria-hidden="true" tabindex="-1"></a><span class="fu">### Incompleteness</span></span>
<span id="cb3-131"><a href="#cb3-131" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-132"><a href="#cb3-132" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Missing edge cases**: Not considering unusual scenarios</span>
<span id="cb3-133"><a href="#cb3-133" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Incomplete examples**: Examples that don't cover all cases</span>
<span id="cb3-134"><a href="#cb3-134" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>**Missing error handling**: Not specifying what happens when things go wrong</span>
<span id="cb3-135"><a href="#cb3-135" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-136"><a href="#cb3-136" aria-hidden="true" tabindex="-1"></a><span class="fu">## Related Rules</span></span>
<span id="cb3-137"><a href="#cb3-137" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-138"><a href="#cb3-138" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="co">[</span><span class="ot">spec-compliance-investigation.mdc</span><span class="co">](mdc:.cursor/rules/spec-compliance-investigation.mdc)</span></span>
<span id="cb3-139"><a href="#cb3-139" aria-hidden="true" tabindex="-1"></a> How to investigate spec-implementation discrepancies</span>
<span id="cb3-140"><a href="#cb3-140" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span><span class="co">[</span><span class="ot">base_overview.mdc</span><span class="co">](mdc:.cursor/rules/base_overview.mdc)</span> Project structure and</span>
<span id="cb3-141"><a href="#cb3-141" aria-hidden="true" tabindex="-1"></a> conventions</span></code><button title="In die Zwischenablage kopieren" class="code-copy-button"><i class="bi"></i></button></pre></div>
</div>
<p>As it is obvious this is a very intricate rule with many criteria. For this you really <strong>need</strong> a reasoning and deep-thinking model that can also reason for extended times (many minutes are normal!) and call tools every now and then to get even more information. Models like <code>o3</code>, <code>deepseek-r1</code> and the <code>opus</code>-series of <code>claude</code> really shine here.</p>
</section>
@ -1201,50 +1217,53 @@ This is most often the most trivial step. Everything is known and formulated for
<span id="cb5-13"><a href="#cb5-13" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-14"><a href="#cb5-14" aria-hidden="true" tabindex="-1"></a><span class="fu">### Output</span></span>
<span id="cb5-15"><a href="#cb5-15" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-16"><a href="#cb5-16" aria-hidden="true" tabindex="-1"></a>• Create /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/TASKS.md (overwrite if it exists). • Markdown only, no</span>
<span id="cb5-17"><a href="#cb5-17" aria-hidden="true" tabindex="-1"></a>prose around it. • Epics = H2 headings (<span class="in">`## 1. &lt;Epic&gt;`</span>). • Tasks = unchecked</span>
<span id="cb5-18"><a href="#cb5-18" aria-hidden="true" tabindex="-1"></a>check‑boxes (<span class="in">`- [ ] 1.1 &lt;task&gt;`</span>). • Sub‑tasks = indent one space under their</span>
<span id="cb5-19"><a href="#cb5-19" aria-hidden="true" tabindex="-1"></a>parent (<span class="in">` - [ ] 1.1.1 &lt;subtask&gt;`</span>). • Create a</span>
<span id="cb5-20"><a href="#cb5-20" aria-hidden="true" tabindex="-1"></a>/tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/Task*&lt;Epic&gt;*<span class="dt">&lt;</span><span class="kw">task</span><span class="dt">&gt;</span><span class="sc">\_</span><span class="dt">&lt;</span><span class="kw">subtask</span><span class="dt">&gt;</span>.md (i.e. <span class="in">`Task_3_2_4.md`</span> for Epic</span>
<span id="cb5-21"><a href="#cb5-21" aria-hidden="true" tabindex="-1"></a>3, Task 2, Subtask 4)</span>
<span id="cb5-22"><a href="#cb5-22" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-23"><a href="#cb5-23" aria-hidden="true" tabindex="-1"></a><span class="fu">### Process</span></span>
<span id="cb5-24"><a href="#cb5-24" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-25"><a href="#cb5-25" aria-hidden="true" tabindex="-1"></a><span class="ss">1. </span>Read the tagged PRD.</span>
<span id="cb5-26"><a href="#cb5-26" aria-hidden="true" tabindex="-1"></a><span class="ss">2. </span>**Investigate** the current state of the repository to collect answers to</span>
<span id="cb5-27"><a href="#cb5-27" aria-hidden="true" tabindex="-1"></a> your first questions. All specs for fixed behaviours and outputs are located</span>
<span id="cb5-28"><a href="#cb5-28" aria-hidden="true" tabindex="-1"></a> in <span class="in">`specs/`</span>. **Consult those** as a source first before trying to</span>
<span id="cb5-29"><a href="#cb5-29" aria-hidden="true" tabindex="-1"></a> reverse-engineer from the code. </span>
<span id="cb5-30"><a href="#cb5-30" aria-hidden="true" tabindex="-1"></a> If specs are in need of change then this is also a task to be generated.</span>
<span id="cb5-31"><a href="#cb5-31" aria-hidden="true" tabindex="-1"></a><span class="ss">3. </span>If critical info is missing and cannot be answered by looking at the code,</span>
<span id="cb5-32"><a href="#cb5-32" aria-hidden="true" tabindex="-1"></a> ask max five clarifying questions (Q1 … Q5) and stop until answered.</span>
<span id="cb5-33"><a href="#cb5-33" aria-hidden="true" tabindex="-1"></a><span class="ss">4. </span>After questions are answered think about the answers and: Either: look at the</span>
<span id="cb5-34"><a href="#cb5-34" aria-hidden="true" tabindex="-1"></a> code again, then goto 3., and ask for further clarification Or: Reply</span>
<span id="cb5-35"><a href="#cb5-35" aria-hidden="true" tabindex="-1"></a> exactly: Ready to generate the subtasks – respond **go** to proceed.</span>
<span id="cb5-36"><a href="#cb5-36" aria-hidden="true" tabindex="-1"></a><span class="ss">5. </span>On a user message that contains only the word "go" (case‑insensitive): a.</span>
<span id="cb5-37"><a href="#cb5-37" aria-hidden="true" tabindex="-1"></a> Generate /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/TASKS.md following _Output_ spec. b. Reply with:</span>
<span id="cb5-38"><a href="#cb5-38" aria-hidden="true" tabindex="-1"></a> TASKS.md created – review them.</span>
<span id="cb5-39"><a href="#cb5-39" aria-hidden="true" tabindex="-1"></a><span class="ss">6. </span>After TASKS.md was reviewed, create <span class="in">`Task_&lt;e&gt;_&lt;t&gt;_&lt;s&gt;.md`</span> for each task and</span>
<span id="cb5-40"><a href="#cb5-40" aria-hidden="true" tabindex="-1"></a> subtask containing implementation hints like relevant specs (link them!),</span>
<span id="cb5-41"><a href="#cb5-41" aria-hidden="true" tabindex="-1"></a> primary files to edit/review for this task, tests needing change, etc.</span>
<span id="cb5-42"><a href="#cb5-42" aria-hidden="true" tabindex="-1"></a><span class="ss">7. </span>Stop. Do **not** begin executing tasks in this rule.</span>
<span id="cb5-43"><a href="#cb5-43" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-44"><a href="#cb5-44" aria-hidden="true" tabindex="-1"></a><span class="fu">### Writing guidelines</span></span>
<span id="cb5-45"><a href="#cb5-45" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-46"><a href="#cb5-46" aria-hidden="true" tabindex="-1"></a>• Each item ≤120 characters, start with an action verb. • Hints are allowed</span>
<span id="cb5-47"><a href="#cb5-47" aria-hidden="true" tabindex="-1"></a>below each item as HTML-Comment and do not count against the 120 characters. •</span>
<span id="cb5-48"><a href="#cb5-48" aria-hidden="true" tabindex="-1"></a>Group related work into logical epics with ≤7 direct child items. • Prefer</span>
<span id="cb5-49"><a href="#cb5-49" aria-hidden="true" tabindex="-1"></a>concrete file paths, commands, specs or APIs when available. • Skip</span>
<span id="cb5-50"><a href="#cb5-50" aria-hidden="true" tabindex="-1"></a>implementation details obvious from the codebase in the overview. • If a task</span>
<span id="cb5-51"><a href="#cb5-51" aria-hidden="true" tabindex="-1"></a>only concerns up to 5 files, name them in the detailed file. Otherwise give</span>
<span id="cb5-52"><a href="#cb5-52" aria-hidden="true" tabindex="-1"></a>hints on how to search for them (i.e. "everything under src/models/").</span>
<span id="cb5-53"><a href="#cb5-53" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-54"><a href="#cb5-54" aria-hidden="true" tabindex="-1"></a><span class="fu">### Safety rails</span></span>
<span id="cb5-55"><a href="#cb5-55" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-56"><a href="#cb5-56" aria-hidden="true" tabindex="-1"></a>• Never touch production data. • Assume all work happens in a feature branch,</span>
<span id="cb5-57"><a href="#cb5-57" aria-hidden="true" tabindex="-1"></a>never commit directly to main. • Check the generated Document with</span>
<span id="cb5-58"><a href="#cb5-58" aria-hidden="true" tabindex="-1"></a><span class="in">`markdownlint`</span> (if available), apply auto-fixes and fix the remaining issues</span>
<span id="cb5-59"><a href="#cb5-59" aria-hidden="true" tabindex="-1"></a>manually.</span></code><button title="In die Zwischenablage kopieren" class="code-copy-button"><i class="bi"></i></button></pre></div>
<span id="cb5-16"><a href="#cb5-16" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Create /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/TASKS.md (overwrite if it exists).</span>
<span id="cb5-17"><a href="#cb5-17" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Markdown only, no prose around it.</span>
<span id="cb5-18"><a href="#cb5-18" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Epics = H2 headings (<span class="in">`## 1. &lt;Epic&gt;`</span>).</span>
<span id="cb5-19"><a href="#cb5-19" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Tasks = unchecked check‑boxes (<span class="in">`- [ ] 1.1 &lt;task&gt;`</span>).</span>
<span id="cb5-20"><a href="#cb5-20" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Sub‑tasks = indent one space under their parent (<span class="in">` - [ ] 1.1.1 &lt;subtask&gt;`</span>).</span>
<span id="cb5-21"><a href="#cb5-21" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Create a /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/Task*&lt;Epic&gt;*<span class="dt">&lt;</span><span class="kw">task</span><span class="dt">&gt;</span><span class="sc">\_</span><span class="dt">&lt;</span><span class="kw">subtask</span><span class="dt">&gt;</span>.md (i.e.</span>
<span id="cb5-22"><a href="#cb5-22" aria-hidden="true" tabindex="-1"></a> <span class="in">`Task_3_2_4.md`</span> for Epic 3, Task 2, Subtask 4)</span>
<span id="cb5-23"><a href="#cb5-23" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-24"><a href="#cb5-24" aria-hidden="true" tabindex="-1"></a><span class="fu">### Process</span></span>
<span id="cb5-25"><a href="#cb5-25" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-26"><a href="#cb5-26" aria-hidden="true" tabindex="-1"></a><span class="ss">1. </span>Read the tagged PRD.</span>
<span id="cb5-27"><a href="#cb5-27" aria-hidden="true" tabindex="-1"></a><span class="ss">2. </span>**Investigate** the current state of the repository to collect answers to</span>
<span id="cb5-28"><a href="#cb5-28" aria-hidden="true" tabindex="-1"></a> your first questions. All specs for fixed behaviours and outputs are located</span>
<span id="cb5-29"><a href="#cb5-29" aria-hidden="true" tabindex="-1"></a> in <span class="in">`specs/`</span>. **Consult those** as a source first before trying to</span>
<span id="cb5-30"><a href="#cb5-30" aria-hidden="true" tabindex="-1"></a> reverse-engineer from the code. </span>
<span id="cb5-31"><a href="#cb5-31" aria-hidden="true" tabindex="-1"></a> If specs are in need of change then this is also a task to be generated.</span>
<span id="cb5-32"><a href="#cb5-32" aria-hidden="true" tabindex="-1"></a><span class="ss">3. </span>If critical info is missing and cannot be answered by looking at the code,</span>
<span id="cb5-33"><a href="#cb5-33" aria-hidden="true" tabindex="-1"></a> ask max five clarifying questions (Q1 … Q5) and stop until answered.</span>
<span id="cb5-34"><a href="#cb5-34" aria-hidden="true" tabindex="-1"></a><span class="ss">4. </span>After questions are answered think about the answers and: Either: look at the</span>
<span id="cb5-35"><a href="#cb5-35" aria-hidden="true" tabindex="-1"></a> code again, then goto 3., and ask for further clarification Or: Reply</span>
<span id="cb5-36"><a href="#cb5-36" aria-hidden="true" tabindex="-1"></a> exactly: Ready to generate the subtasks – respond **go** to proceed.</span>
<span id="cb5-37"><a href="#cb5-37" aria-hidden="true" tabindex="-1"></a><span class="ss">5. </span>On a user message that contains only the word "go" (case‑insensitive): a.</span>
<span id="cb5-38"><a href="#cb5-38" aria-hidden="true" tabindex="-1"></a> Generate /tasks/<span class="dt">&lt;</span><span class="kw">feature</span><span class="dt">&gt;</span>/TASKS.md following _Output_ spec. b. Reply with:</span>
<span id="cb5-39"><a href="#cb5-39" aria-hidden="true" tabindex="-1"></a> TASKS.md created – review them.</span>
<span id="cb5-40"><a href="#cb5-40" aria-hidden="true" tabindex="-1"></a><span class="ss">6. </span>After TASKS.md was reviewed, create <span class="in">`Task_&lt;e&gt;_&lt;t&gt;_&lt;s&gt;.md`</span> for each task and</span>
<span id="cb5-41"><a href="#cb5-41" aria-hidden="true" tabindex="-1"></a> subtask containing implementation hints like relevant specs (link them!),</span>
<span id="cb5-42"><a href="#cb5-42" aria-hidden="true" tabindex="-1"></a> primary files to edit/review for this task, tests needing change, etc.</span>
<span id="cb5-43"><a href="#cb5-43" aria-hidden="true" tabindex="-1"></a><span class="ss">7. </span>Stop. Do **not** begin executing tasks in this rule.</span>
<span id="cb5-44"><a href="#cb5-44" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-45"><a href="#cb5-45" aria-hidden="true" tabindex="-1"></a><span class="fu">### Writing guidelines</span></span>
<span id="cb5-46"><a href="#cb5-46" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-47"><a href="#cb5-47" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Each item ≤120 characters, start with an action verb.</span>
<span id="cb5-48"><a href="#cb5-48" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Hints are allowed below each item as HTML-Comment and do not count against the</span>
<span id="cb5-49"><a href="#cb5-49" aria-hidden="true" tabindex="-1"></a> 120 characters.</span>
<span id="cb5-50"><a href="#cb5-50" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Group related work into logical epics with ≤7 direct child items.</span>
<span id="cb5-51"><a href="#cb5-51" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Prefer concrete file paths, commands, specs or APIs when available.</span>
<span id="cb5-52"><a href="#cb5-52" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Skip implementation details obvious from the codebase in the overview.</span>
<span id="cb5-53"><a href="#cb5-53" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>If a task only concerns up to 5 files, name them in the detailed file.</span>
<span id="cb5-54"><a href="#cb5-54" aria-hidden="true" tabindex="-1"></a> Otherwise give hints on how to search for them (i.e. "everything under</span>
<span id="cb5-55"><a href="#cb5-55" aria-hidden="true" tabindex="-1"></a> <span class="in">`src/models/`</span>").</span>
<span id="cb5-56"><a href="#cb5-56" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-57"><a href="#cb5-57" aria-hidden="true" tabindex="-1"></a><span class="fu">### Safety rails</span></span>
<span id="cb5-58"><a href="#cb5-58" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-59"><a href="#cb5-59" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Never touch production data.</span>
<span id="cb5-60"><a href="#cb5-60" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Assume all work happens in a feature branch, never commit directly to main.</span>
<span id="cb5-61"><a href="#cb5-61" aria-hidden="true" tabindex="-1"></a><span class="ss">- </span>Check the generated Document with <span class="in">`markdownlint`</span> (if available), apply</span>
<span id="cb5-62"><a href="#cb5-62" aria-hidden="true" tabindex="-1"></a> auto-fixes and fix the remaining issues manually.</span></code><button title="In die Zwischenablage kopieren" class="code-copy-button"><i class="bi"></i></button></pre></div>
</div>
<p>This also works better with one of those deep-thinking models.</p>
</section>
@ -1256,7 +1275,7 @@ This is most often the most trivial step. Everything is known and formulated for
</section>
<section id="example-rules-in-action" class="level2 page-columns page-full">
<h2 class="anchored" data-anchor-id="example-rules-in-action">Example: Rules in Action</h2>
<p>The codebase we look at here is a project called <code>gitlab_overviewer</code>. It takes gitlab-api-keys and generates nice overviews for tracking metadata in different projects across different groups. With a nice export to markdown (for rendering in gitlab itself) and quarto (for exporting to i.e.&nbsp;confluence) with multiple pages etc. pp.</p>
<p>The codebase we look at here is a project called <code>gitlab_overviewer</code>. It takes GitLab-api-keys and generates nice overviews for tracking metadata in different projects across different groups. With a nice export to markdown (for rendering in GitLab itself) and quarto (for exporting to i.e.&nbsp;confluence) with multiple pages etc. pp.</p>
<p>The current issue is, that due to a complete rewrite we are happy with the current output, but there are some minor problems still remaining. Some of them may also due to specs being incorrect, because requirements or ideas changed over time.</p>
<section id="analyzing-the-situation" class="level3 page-columns page-full">
<h3 class="anchored">Analyzing the situation</h3>
@ -1728,7 +1747,7 @@ Cursor
<li><strong>Project Integrity</strong>: Through rigorous spec adherence and systematic task breakdown, the codebase is more consistent, much better documented and decently tested<a href="#fn5" class="footnote-ref" id="fnref5" role="doc-noteref"><sup>5</sup></a>.</li>
<li><strong>Reduced Cognitive Load</strong>: The Cursor rule system has made it easier to focus on actual development tasks instead of wrestling with the AI’s sometimes questionable assumptions - or just installing a third different testing framework for exactly this module.</li>
</ul>
<div class="no-row-height column-margin column-container"><div id="fn5"><p><sup>5</sup>&nbsp;You know.. noone likes writing tests - and the person writing the code should never write the tests anyway. If you haven’t thought of something while coding, chanches are, that you miss that edge-case during testing as well.</p></div></div><p>In this <code>gitlab_overviewer</code> case study, i tried to show at an easy example, that this method works and <em>can</em> yields great outcomes. Even small discrepancies in the codebase tend to pop up during spec-reviews (which can be automated!). Next up would be running those in some kind of CI-job and integrating tools like issue-tracking into the agent instead of simple markdown-files in the repository as makeshift issue-tracker. But not by me for the forseeable future, so if you are looking for a project, feel free!</p>
<div class="no-row-height column-margin column-container"><div id="fn5"><p><sup>5</sup>&nbsp;You know.. noone likes writing tests - and the person writing the code should never write the tests anyway. If you haven’t thought of something while coding, chanches are, that you miss that edge-case during testing as well.</p></div></div><p>In this <code>gitlab_overviewer</code> case study, i tried to show at an easy example, that this method works and <em>can</em> yields great outcomes. Even small discrepancies in the codebase tend to pop up during spec-reviews (which can be automated!). Next up would be running those in some kind of CI-job and integrating tools like issue-tracking into the agent instead of simple markdown-files in the repository as makeshift issue-tracker. But not by me for the foreseeable future, so if you are looking for a project, feel free!</p>
<p><strong>All in all this isn’t a silver bullet for all AI-assisted development problems, but it’s made my coding experience with Cursor much more productive and predictable. It turns out treating an AI as a slightly overeager junior developer who needs clear instructions works better than hoping it’ll just “do the right thing”.</strong></p>

66
dist/index.html vendored
View File

@ -648,7 +648,7 @@ window.Quarto = {
<ul>
<li><a href="#letzte-posts" id="toc-letzte-posts" class="nav-link active" data-scroll-target="#letzte-posts">Letzte Posts</a></li>
</ul>
<div class="quarto-other-links"><h2>Other Links</h2><ul><li><a href="https://toot.kif.rocks/@Drezil" rel="me"><i class="bi bi-mastodon"></i>Mastodon</a></li><li><a href="https://github.com/Drezil" rel="me"><i class="bi bi-github"></i>Github</a></li></ul></div></nav>
<div class="quarto-other-links"><h2>Other Links</h2><ul><li><a href="https://gitea.dresselhaus.cloud/Drezil" rel="me"><i class="bi bi-cup-hot-fill"></i>Gitea</a></li><li><a href="https://toot.kif.rocks/@Drezil" rel="me"><i class="bi bi-mastodon"></i>Mastodon</a></li><li><a href="https://github.com/Drezil" rel="me"><i class="bi bi-github"></i>Github</a></li></ul></div></nav>
<h5 class="quarto-listing-category-title">Categories</h5><div class="quarto-listing-category category-cloud"><div class="category" data-category="QXJjaGl2ZWQ="><span class="quarto-category-count category-cloud-2">Archived</span></div><div class="category" data-category="QXJ0aWNsZQ=="><span class="quarto-category-count category-cloud-5">Article</span></div><div class="category" data-category="QmVpc3BpZWw="><span class="quarto-category-count category-cloud-1">Beispiel</span></div><div class="category" data-category="QmVzdCUyMFByYWN0aWNlcw=="><span class="quarto-category-count category-cloud-1">Best Practices</span></div><div class="category" data-category="Q2FzZS1zdHVkeQ=="><span class="quarto-category-count category-cloud-1">Case-study</span></div><div class="category" data-category="Q29kZQ=="><span class="quarto-category-count category-cloud-2">Code</span></div><div class="category" data-category="RXhwZXJpZW5jZQ=="><span class="quarto-category-count category-cloud-2">Experience</span></div><div class="category" data-category="RnVu"><span class="quarto-category-count category-cloud-1">Fun</span></div><div class="category" data-category="SGFza2VsbA=="><span class="quarto-category-count category-cloud-5">Haskell</span></div><div class="category" data-category="TGVjdHVyZQ=="><span class="quarto-category-count category-cloud-1">Lecture</span></div><div class="category" data-category="TGlua3M="><span class="quarto-category-count category-cloud-1">Links</span></div><div class="category" data-category="TWVudGFsJTIwSGVhbHRo"><span class="quarto-category-count category-cloud-1">Mental Health</span></div><div class="category" data-category="TUw="><span class="quarto-category-count category-cloud-2">ML</span></div><div class="category" data-category="TkVS"><span class="quarto-category-count category-cloud-1">NER</span></div><div class="category" data-category="UHJheGlz"><span class="quarto-category-count category-cloud-1">Praxis</span></div><div class="category" data-category="UkFH"><span class="quarto-category-count category-cloud-1">RAG</span></div><div class="category" data-category="U3RydWdnbGVz"><span class="quarto-category-count category-cloud-1">Struggles</span></div><div class="category" data-category="VHV0b3JpYWw="><span class="quarto-category-count category-cloud-2">Tutorial</span></div><div class="category" data-category="VW5p"><span class="quarto-category-count category-cloud-1">Uni</span></div></div></div>
<!-- main -->
<main class="content" id="quarto-document-content">
@ -684,7 +684,7 @@ window.Quarto = {
<div class="quarto-listing quarto-listing-container-grid" id="listing-listing">
<div class="list grid quarto-listing-cols-3">
<div class="g-col-1" data-index="0" data-listing-date-sort="1750888800000" data-listing-file-modified-sort="1750971898361" data-listing-date-modified-sort="NaN" data-listing-reading-time-sort="30" data-listing-word-count-sort="5859">
<div class="g-col-1" data-index="0" data-listing-date-sort="1750888800000" data-listing-file-modified-sort="1751197563135" data-listing-date-modified-sort="NaN" data-listing-reading-time-sort="30" data-listing-word-count-sort="5905">
<a href="./Writing/coding-age-ai.html" class="quarto-grid-link">
<div class="quarto-grid-item card h-100 card-left">
<p class="card-img-top">
@ -898,7 +898,7 @@ April 1, 2020
</div>
</div></a>
</div>
<div class="g-col-1" data-index="7" data-categories="SGFza2VsbCUyQ1R1dG9yaWFs" data-listing-date-sort="1585692000000" data-listing-file-modified-sort="1746818412478" data-listing-date-modified-sort="NaN" data-listing-reading-time-sort="28" data-listing-word-count-sort="5546">
<div class="g-col-1" data-index="7" data-categories="SGFza2VsbCUyQ1R1dG9yaWFs" data-listing-date-sort="1585692000000" data-listing-file-modified-sort="1751196644156" data-listing-date-modified-sort="NaN" data-listing-reading-time-sort="28" data-listing-word-count-sort="5542">
<a href="./Coding/Haskell/Webapp-Example/index.html" class="quarto-grid-link">
<div class="quarto-grid-item card h-100 card-left">
<p class="card-img-top"><img src="./thumbs/placeholder.png" style="height: 200;" class="thumbnail-image card-img"/></p>
@ -958,36 +958,7 @@ January 1, 2019
</div>
</div></a>
</div>
<div class="g-col-1" data-index="9" data-categories="TGVjdHVyZSUyQ0hhc2tlbGw=" data-listing-date-sort="1514761200000" data-listing-file-modified-sort="1746774471739" data-listing-date-modified-sort="NaN" data-listing-reading-time-sort="2" data-listing-word-count-sort="374">
<a href="./Coding/Haskell/FFPiH.html" class="quarto-grid-link">
<div class="quarto-grid-item card h-100 card-left">
<p class="card-img-top"><img src="./thumbs/placeholder.png" style="height: 200;" class="thumbnail-image card-img"/></p>
<div class="card-body post-contents">
<h5 class="no-anchor card-title listing-title">
Fortgeschrittene funktionale Programmierung in Haskell
</h5>
<div class="listing-categories">
<div class="listing-category" onclick="window.quartoListingCategory('TGVjdHVyZQ=='); return false;">Lecture</div>
<div class="listing-category" onclick="window.quartoListingCategory('SGFza2VsbA=='); return false;">Haskell</div>
</div>
<div class="card-text listing-description delink">
FFPiH ist eine Vorlesung, die ich zusammen mit einem Kommilitonen im Sommer 2015 erstmals erstellt und gehalten haben.
</div>
<div class="card-attribution card-text-small justify">
<div class="listing-author">
</div>
<div class="listing-date">
January 1, 2018
</div>
</div>
</div>
</div></a>
</div>
<div class="g-col-1" data-index="10" data-categories="QXJ0aWNsZSUyQ0hhc2tlbGw=" data-listing-date-sort="1514761200000" data-listing-file-modified-sort="1746774626159" data-listing-date-modified-sort="NaN" data-listing-reading-time-sort="17" data-listing-word-count-sort="3277">
<div class="g-col-1" data-index="9" data-categories="QXJ0aWNsZSUyQ0hhc2tlbGw=" data-listing-date-sort="1514761200000" data-listing-file-modified-sort="1746774626159" data-listing-date-modified-sort="NaN" data-listing-reading-time-sort="17" data-listing-word-count-sort="3277">
<a href="./Coding/Haskell/Lenses.html" class="quarto-grid-link">
<div class="quarto-grid-item card h-100 card-left">
<p class="card-img-top"><img src="./thumbs/placeholder.png" style="height: 200;" class="thumbnail-image card-img"/></p>
@ -1010,6 +981,35 @@ Syntax nehmen.
<div class="card-attribution card-text-small justify">
<div class="listing-author">
</div>
<div class="listing-date">
January 1, 2018
</div>
</div>
</div>
</div></a>
</div>
<div class="g-col-1" data-index="10" data-categories="TGVjdHVyZSUyQ0hhc2tlbGw=" data-listing-date-sort="1514761200000" data-listing-file-modified-sort="1751196904263" data-listing-date-modified-sort="NaN" data-listing-reading-time-sort="2" data-listing-word-count-sort="374">
<a href="./Coding/Haskell/FFPiH.html" class="quarto-grid-link">
<div class="quarto-grid-item card h-100 card-left">
<p class="card-img-top"><img src="./thumbs/placeholder.png" style="height: 200;" class="thumbnail-image card-img"/></p>
<div class="card-body post-contents">
<h5 class="no-anchor card-title listing-title">
Fortgeschrittene funktionale Programmierung in Haskell
</h5>
<div class="listing-categories">
<div class="listing-category" onclick="window.quartoListingCategory('TGVjdHVyZQ=='); return false;">Lecture</div>
<div class="listing-category" onclick="window.quartoListingCategory('SGFza2VsbA=='); return false;">Haskell</div>
</div>
<div class="card-text listing-description delink">
FFPiH ist eine Vorlesung, die ich zusammen mit einem Kommilitonen im Sommer 2015 erstmals erstellt und gehalten haben.
</div>
<div class="card-attribution card-text-small justify">
<div class="listing-author">
</div>
<div class="listing-date">
January 1, 2018

627
dist/index.xml vendored
View File

@ -22,17 +22,17 @@
<section id="introduction" class="level2 page-columns page-full">
<h2 class="anchored" data-anchor-id="introduction">Introduction</h2>
<p>In the fast eveolving field of AI there is a clear lack of reports on “what really works”. Some techniques hailed as revolution (like the DeepSeek Aha-Moment<span class="citation" data-cites="DeepSeek-AI2025DeepSeekR1IncentivizingReasoning">[1]</span>) for unlimited potential were soon realized to “just” optimize nieche problems that can benchmarked<span class="citation" data-cites="Shao2025SpuriousRewardsRethinking">[2]</span><sup>1</sup>.</p>
<div class="no-row-height column-margin column-container"><div id="fn1"><p><sup>1</sup>&nbsp;Like all decent humans i ain’t got time to read up on everything - so a big shoutout to <span class="citation" data-cites="bycloud2025LLMsRLRevelation">[3]</span> for doing thorough reviews on ML-topics and linking the respective papers!</p></div><div id="fn2"><p><sup>2</sup>&nbsp;i.e.&nbsp;the “base model” nearly all papers tested their finding on (qwen-series) also gets better with RLVR-optimization if rewards are random instead of verified</p></div></div><p>I personally think it is an exercise in futility to get a <em>current</em> theoretical overview for forming a decent grounded opinion on the state of things. Even before one is done analyzing the literature, crossrefercencing and collecting evidence and then finally formulating methods and implementing them, the next revolution comes around that could put everything on its head again. In the afromentioned example the community went from “Reasoning is the solution” in January<span class="citation" data-cites="DeepSeek-AI2025DeepSeekR1IncentivizingReasoning">[1]</span> over first critical views in March<span class="citation" data-cites="Liu2025UnderstandingR1ZeroLikeTraining">[4]</span> to doubts on that claims validity of generating concepts previously not present in the base model in May<span class="citation" data-cites="Mukherjee2025ReinforcementLearningFinetunes">[5]</span> to complete ad-absurdum in June<span class="citation" data-cites="Shao2025SpuriousRewardsRethinking">[2]</span><sup>2</sup>.</p>
<p>Therefore see this “Field Guide” for what it is: A current state of things that work for at least 1 individuum in exactly this ecosystem at this point in time.</p>
<p>In the fast evolving field of AI there is a clear lack of reports on “what really works”. Some techniques hailed as revolution (like the DeepSeek Aha-Moment<span class="citation" data-cites="DeepSeek-AI2025DeepSeekR1IncentivizingReasoning">[1]</span>) for unlimited potential were soon realized to “just” optimize niche problems that can benchmarked<span class="citation" data-cites="Shao2025SpuriousRewardsRethinking">[2]</span><sup>1</sup>.</p>
<div class="no-row-height column-margin column-container"><div id="fn1"><p><sup>1</sup>&nbsp;Like all decent humans i ain’t got time to read up on everything - so a big shoot-out to <span class="citation" data-cites="bycloud2025LLMsRLRevelation">[3]</span> for doing thorough reviews on ML-topics and linking the respective papers!</p></div><div id="fn2"><p><sup>2</sup>&nbsp;i.e.&nbsp;the “base model” nearly all papers tested their finding on (qwen-series) also gets better with RLVR-optimization if rewards are random instead of verified</p></div></div><p>I personally think it is an exercise in futility to get a <em>current</em> theoretical overview for forming a decent grounded opinion on the state of things. Even before one is done analyzing the literature, crossrefercencing and collecting evidence and then finally formulating methods and implementing them, the next revolution comes around that could put everything on its head again. In the afromentioned example the community went from “Reasoning is the solution” in January<span class="citation" data-cites="DeepSeek-AI2025DeepSeekR1IncentivizingReasoning">[1]</span> over first critical views in March<span class="citation" data-cites="Liu2025UnderstandingR1ZeroLikeTraining">[4]</span> to doubts on that claims validity of generating concepts previously not present in the base model in May<span class="citation" data-cites="Mukherjee2025ReinforcementLearningFinetunes">[5]</span> to complete ad-absurdum in June<span class="citation" data-cites="Shao2025SpuriousRewardsRethinking">[2]</span><sup>2</sup>.</p>
<p>Therefore see this “Field Guide” for what it is: A current state of things that work for at least 1 Individuum in exactly this ecosystem at this point in time.</p>
</section>
<section id="how-to-program-with-cursor" class="level2">
<h2 class="anchored" data-anchor-id="how-to-program-with-cursor">How to program with Cursor</h2>
<p>In essence <a href="https://cursor.com">Cursor</a> is “just” a fork of <a href="https://code.visualstudio.com/">Microsofts VSCode</a> with some added functionality: Automatically injecting files into LLM-Prompts, offering tool-aware LLMs to use <a href="https://modelcontextprotocol.io/introduction">MCP</a>s, read the filesystem, execute arbitrary commands in the shell (either automomatically or after permission), getting feedback from the editor (i.e. installed linters, language-servers etc.) and thus have the same (or even better) information/tools available as the programmer in front of the screen.</p>
<p>In essence <a href="https://cursor.com">Cursor</a> is “just” a fork of <a href="https://code.visualstudio.com/">Microsofts VSCode</a> with some added functionality: Automatically injecting files into LLM-Prompts, offering tool-aware LLMs to use <a href="https://modelcontextprotocol.io/introduction">MCP</a>s, read the filesystem, execute arbitrary commands in the shell (either automatically or after permission), getting feedback from the editor (i.e. installed linters, language-servers etc.) and thus have the same (or even better) information/tools available as the programmer in front of the screen.</p>
<section id="capabilities-general-procedure" class="level3">
<h3 class="anchored" data-anchor-id="capabilities-general-procedure">Capabilities / General procedure</h3>
<p>The main issue is now: theoretically agentic IDEs can get all information - practically it is limited directly by token-window sizes, costs of these queries; and indirectly by outsourced costs like environmental impacts, data-security, etc. The suppliers of such services can claim privacy as much as they want - it can’t be proven and (especially under US-Law) is not even possible to resist lawful orders (including the gag-order to not talk about these).</p>
<p>In practise one feels the direct pain points more severly. Some regular examples include generating redundant code, because the current context was not aware of utility-modules and functions it could use - leading to huge technical debt in no time.</p>
<p>In practise one feels the direct pain points more severely. Some regular examples include generating redundant code, because the current context was not aware of utility-modules and functions it could use - leading to huge technical debt in no time.</p>
<p>Therefore my preferred workflow is to “think bigger”. Imagine being a product owner of a huge, sluggish company. The left hand never knows what the right hand does or has done (i.e.&nbsp;the LLM forgetting things already exist in the codebase), everything has to be rigorous defined, specified and enforced. Some people reported good results with Test-Driven-Development (TDD) - but in my experience these things only prevent regressions and not proactively enforce the desired agent behaviour.</p>
</section>
<section id="lessons-from-project-management" class="level3">
@ -47,9 +47,9 @@ This could be a bug, a feature, some changes to existing behaviour etc.</li>
This dives into the codebase to asses the current state of things. Maybe some bugs are obvious and easily fixed.<br>
This formalizes that the LLM understood what <em>should</em> be done and especially what is <em>out of scope</em>.</li>
<li>Pin the desired behaviour in a <strong>Specification</strong>.<br>
Either this means changing currently established specifications (i.e. bug/chang) or writing complete new ones (i.e.&nbsp;feature).</li>
Either this means changing currently established specifications (i.e. bug/change) or writing complete new ones (i.e.&nbsp;feature).</li>
<li>Investigate <strong>Spec-Compliance</strong>.<br>
Again the agentlooks at the codebase to identify <em>where</em> things should change and <em>how</em>. Also recommendation are made on how it could achieve the goal.</li>
Again the agent looks at the codebase to identify <em>where</em> things should change and <em>how</em>. Also recommendation are made on how it could achieve the goal.</li>
<li>Generate <strong>Tasks</strong>.<br>
From the compliance-report of spec-deviations (either from a bug or from a new/changed spec) finally a Plan to fix everything can be derived (think: Sprint-Planning).</li>
<li><strong>NOTE: Up to here the agent never touched the code.</strong></li>
@ -206,15 +206,26 @@ font-style: inherit;">### Purpose</span></span>
background-color: null;
font-style: inherit;">### Output</span></span>
<span id="cb2-15"></span>
<span id="cb2-16">• Create /tasks/<span class="dt" style="color: #AD0000;
<span id="cb2-16"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Create /tasks/<span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&lt;</span><span class="kw" style="color: #003B4F;
background-color: null;
font-weight: bold;
font-style: inherit;">feature</span><span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&gt;</span>/PRD.md • Markdown only – no prose, no code‑fences. •</span>
<span id="cb2-17">File structure: # <span class="dt" style="color: #AD0000;
font-style: inherit;">&gt;</span>/PRD.md</span>
<span id="cb2-17"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Markdown only – no prose, no code‑fences.</span>
<span id="cb2-18"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>File structure:</span>
<span id="cb2-19"></span>
<span id="cb2-20"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; # </span><span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&lt;</span><span class="kw" style="color: #003B4F;
background-color: null;
@ -223,45 +234,94 @@ font-style: inherit;">Feature</span><span class="ot" style="color: #003B4F;
background-color: null;
font-style: inherit;"> title</span><span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&gt;</span> ## 1. Problem / Motivation ## 2. Goals ## 3.</span>
<span id="cb2-18">Non‑Goals ## 4. Target Users &amp; Personas ## 5. User Stories (Gherkin</span>
<span id="cb2-19">“Given/When/Then”) ## 6. Acceptance Criteria ## 7. Technical Notes /</span>
<span id="cb2-20">Dependencies ## 8. Open Questions</span>
<span id="cb2-21"></span>
<span id="cb2-22"><span class="fu" style="color: #4758AB;
font-style: inherit;">&gt;</span></span>
<span id="cb2-21"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt;</span></span>
<span id="cb2-22"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; ## 1. Problem / Motivation</span></span>
<span id="cb2-23"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt;</span></span>
<span id="cb2-24"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; ## 2. Goals</span></span>
<span id="cb2-25"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt;</span></span>
<span id="cb2-26"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; ## 3. Non‑Goals</span></span>
<span id="cb2-27"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt;</span></span>
<span id="cb2-28"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; ## 4. Target Users &amp; Personas</span></span>
<span id="cb2-29"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt;</span></span>
<span id="cb2-30"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; ## 5. User Stories (Gherkin “Given/When/Then”)</span></span>
<span id="cb2-31"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt;</span></span>
<span id="cb2-32"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; ## 6. Acceptance Criteria</span></span>
<span id="cb2-33"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt;</span></span>
<span id="cb2-34"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; ## 7. Technical Notes / Dependencies</span></span>
<span id="cb2-35"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt;</span></span>
<span id="cb2-36"><span class="at" style="color: #657422;
background-color: null;
font-style: inherit;"> &gt; ## 8. Open Questions</span></span>
<span id="cb2-37"></span>
<span id="cb2-38"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Process</span></span>
<span id="cb2-23"></span>
<span id="cb2-24"><span class="ss" style="color: #20794D;
<span id="cb2-39"></span>
<span id="cb2-40"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">1. </span>Stakeholder provides a single‑sentence feature idea and invokes this rule.</span>
<span id="cb2-25"><span class="ss" style="color: #20794D;
<span id="cb2-41"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">2. </span>Look at specifications in <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`specs/`</span> and inspect the code if needed to get an</span>
<span id="cb2-26"> idea what the Stakeholder expects from this feature.</span>
<span id="cb2-27"><span class="ss" style="color: #20794D;
<span id="cb2-42"> idea what the Stakeholder expects from this feature.</span>
<span id="cb2-43"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">3. </span>Ask up to five clarifying questions (Q1 … Q5). If anything is still vague</span>
<span id="cb2-28"> after five, look into the project with the new information provided. You may</span>
<span id="cb2-29"> ask for further clarification up to 3 times following this schema, else flag</span>
<span id="cb2-30"> it in _Open Questions_.</span>
<span id="cb2-31"><span class="ss" style="color: #20794D;
<span id="cb2-44"> after five, look into the project with the new information provided. You may</span>
<span id="cb2-45"> ask for further clarification up to 3 times following this schema, else flag</span>
<span id="cb2-46"> it in _Open Questions_.</span>
<span id="cb2-47"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">4. </span>After questions are answered reply exactly: Ready to generate the PRD.</span>
<span id="cb2-32"><span class="ss" style="color: #20794D;
<span id="cb2-48"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">5. </span>On a user message that contains only the word "go" (case‑insensitive): •</span>
<span id="cb2-33"> Generate /tasks/<span class="dt" style="color: #AD0000;
font-style: inherit;">5. </span>On a user message that contains only the word "go" (case‑insensitive):</span>
<span id="cb2-49"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Generate /tasks/<span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&lt;</span><span class="kw" style="color: #003B4F;
background-color: null;
font-weight: bold;
font-style: inherit;">feature</span><span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&gt;</span>/PRD.md following _Output_ spec. • Reply:</span>
<span id="cb2-34"> <span class="dt" style="color: #AD0000;
font-style: inherit;">&gt;</span>/PRD.md following _Output_ spec.</span>
<span id="cb2-50"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Reply: <span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&lt;</span><span class="kw" style="color: #003B4F;
background-color: null;
@ -269,28 +329,45 @@ font-weight: bold;
font-style: inherit;">feature</span><span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&gt;</span>/PRD.md created – review it.</span>
<span id="cb2-35"><span class="ss" style="color: #20794D;
<span id="cb2-51"></span>
<span id="cb2-52"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">6. </span>STOP. Do **not** generate tasks or code in this rule.</span>
<span id="cb2-36"></span>
<span id="cb2-37"><span class="fu" style="color: #4758AB;
<span id="cb2-53"></span>
<span id="cb2-54"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Writing guidelines</span></span>
<span id="cb2-38"></span>
<span id="cb2-39">• Keep each bullet ≤120 characters. • Use action verbs and measurable language.</span>
<span id="cb2-40">• Leave TBDs only in _Open Questions_. • No business fluff – pretend the reader</span>
<span id="cb2-41">is a junior developer.</span>
<span id="cb2-42"></span>
<span id="cb2-43"><span class="fu" style="color: #4758AB;
<span id="cb2-55"></span>
<span id="cb2-56"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Keep each bullet ≤120 characters.</span>
<span id="cb2-57"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Use action verbs and measurable language.</span>
<span id="cb2-58"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Leave TBDs only in _Open Questions_.</span>
<span id="cb2-59"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>No business fluff – pretend the reader is a junior developer.</span>
<span id="cb2-60"></span>
<span id="cb2-61"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Safety rails</span></span>
<span id="cb2-44"></span>
<span id="cb2-45">• Assume all work happens in a non‑production environment, unless otherwise</span>
<span id="cb2-46">stated or requested by you. • Do not include sensitive data or credentials in</span>
<span id="cb2-47">the PRD. • Check the generated Document with <span class="in" style="color: #5E5E5E;
<span id="cb2-62"></span>
<span id="cb2-63"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">`markdownlint`</span> (if available),</span>
<span id="cb2-48">apply auto-fixes and fix the remaining issues manually.</span></code></pre></div>
font-style: inherit;">- </span>Assume all work happens in a non‑production environment, unless otherwise</span>
<span id="cb2-64"> stated or requested by you.</span>
<span id="cb2-65"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Do not include sensitive data or credentials in the PRD.</span>
<span id="cb2-66"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Check the generated Document with <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`markdownlint`</span> (if available), apply</span>
<span id="cb2-67"> auto-fixes and fix the remaining issues manually.</span></code></pre></div>
</div>
<p>A call to this rule usually looks like <code>@generate-prd We noticed, that …. Therefore investigate the codebase to come up with a PRD addressing these issues.</code>.</p>
</section>
@ -368,296 +445,293 @@ font-style: inherit;">```</span></span>
<span id="cb3-29"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">2. </span>**Scope and Boundaries**</span>
<span id="cb3-30"></span>
<span id="cb3-31"><span class="ss" style="color: #20794D;
<span id="cb3-30"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>What is included/excluded</span>
<span id="cb3-32"><span class="ss" style="color: #20794D;
<span id="cb3-31"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Dependencies on other specifications</span>
<span id="cb3-33"><span class="ss" style="color: #20794D;
<span id="cb3-32"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Relationship to other components</span>
<span id="cb3-34"></span>
<span id="cb3-35"><span class="ss" style="color: #20794D;
<span id="cb3-33"></span>
<span id="cb3-34"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">3. </span>**Detailed Requirements**</span>
<span id="cb3-36"></span>
<span id="cb3-37"><span class="ss" style="color: #20794D;
<span id="cb3-35"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Structured by logical sections</span>
<span id="cb3-38"><span class="ss" style="color: #20794D;
<span id="cb3-36"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Clear, unambiguous language</span>
<span id="cb3-39"><span class="ss" style="color: #20794D;
<span id="cb3-37"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Examples where helpful</span>
<span id="cb3-40"></span>
<span id="cb3-41"><span class="ss" style="color: #20794D;
<span id="cb3-38"></span>
<span id="cb3-39"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">4. </span>**Error Handling**</span>
<span id="cb3-42"></span>
<span id="cb3-43"><span class="ss" style="color: #20794D;
<span id="cb3-40"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>How errors should be handled</span>
<span id="cb3-44"><span class="ss" style="color: #20794D;
<span id="cb3-41"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Fallback behaviors</span>
<span id="cb3-45"><span class="ss" style="color: #20794D;
<span id="cb3-42"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Edge cases</span>
<span id="cb3-46"></span>
<span id="cb3-47"><span class="ss" style="color: #20794D;
<span id="cb3-43"></span>
<span id="cb3-44"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">5. </span>**Testing Requirements**</span>
<span id="cb3-48"><span class="ss" style="color: #20794D;
<span id="cb3-45"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Expected test coverage</span>
<span id="cb3-49"><span class="ss" style="color: #20794D;
<span id="cb3-46"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Snapshot requirements</span>
<span id="cb3-50"><span class="ss" style="color: #20794D;
<span id="cb3-47"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;"> - </span>Approval test criteria</span>
<span id="cb3-51"></span>
<span id="cb3-52"><span class="fu" style="color: #4758AB;
<span id="cb3-48"></span>
<span id="cb3-49"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">## Writing Standards</span></span>
<span id="cb3-53"></span>
<span id="cb3-54"><span class="fu" style="color: #4758AB;
<span id="cb3-50"></span>
<span id="cb3-51"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Clarity and Precision</span></span>
<span id="cb3-55"></span>
<span id="cb3-56"><span class="ss" style="color: #20794D;
<span id="cb3-52"></span>
<span id="cb3-53"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Use specific language**: Avoid vague terms like "should" or "might"</span>
<span id="cb3-57"><span class="ss" style="color: #20794D;
<span id="cb3-54"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Provide examples**: Include concrete examples for complex requirements</span>
<span id="cb3-58"><span class="ss" style="color: #20794D;
<span id="cb3-55"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Define terms**: Clearly define any technical terms or concepts</span>
<span id="cb3-59"><span class="ss" style="color: #20794D;
<span id="cb3-56"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Use consistent formatting**: Follow established patterns from existing specs</span>
<span id="cb3-60"></span>
<span id="cb3-61"><span class="fu" style="color: #4758AB;
<span id="cb3-57"></span>
<span id="cb3-58"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Structure and Organization</span></span>
<span id="cb3-62"></span>
<span id="cb3-63"><span class="ss" style="color: #20794D;
<span id="cb3-59"></span>
<span id="cb3-60"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Logical flow**: Organize sections in logical order</span>
<span id="cb3-64"><span class="ss" style="color: #20794D;
<span id="cb3-61"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Consistent headings**: Use consistent heading levels and naming</span>
<span id="cb3-65"><span class="ss" style="color: #20794D;
<span id="cb3-62"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Cross-references**: Link to related specifications using</span>
<span id="cb3-66"> <span class="in" style="color: #5E5E5E;
<span id="cb3-63"> <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`[spec_name](mdc:specs/spec_name.md)`</span></span>
<span id="cb3-67"><span class="ss" style="color: #20794D;
<span id="cb3-64"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Code blocks**: Use appropriate language tags for code examples</span>
<span id="cb3-68"></span>
<span id="cb3-69"><span class="fu" style="color: #4758AB;
<span id="cb3-65"></span>
<span id="cb3-66"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Completeness</span></span>
<span id="cb3-70"></span>
<span id="cb3-71"><span class="ss" style="color: #20794D;
<span id="cb3-67"></span>
<span id="cb3-68"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Cover all cases**: Address normal, error, and edge cases</span>
<span id="cb3-72"><span class="ss" style="color: #20794D;
<span id="cb3-69"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Be exhaustive**: Don't assume implementation details</span>
<span id="cb3-73"><span class="ss" style="color: #20794D;
<span id="cb3-70"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Consider interactions**: How this spec relates to others</span>
<span id="cb3-74"><span class="ss" style="color: #20794D;
<span id="cb3-71"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Future-proof**: Consider potential changes and extensions</span>
<span id="cb3-75"></span>
<span id="cb3-76"><span class="fu" style="color: #4758AB;
<span id="cb3-72"></span>
<span id="cb3-73"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">## Specification Maintenance</span></span>
<span id="cb3-77"></span>
<span id="cb3-78"><span class="fu" style="color: #4758AB;
<span id="cb3-74"></span>
<span id="cb3-75"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Version Control</span></span>
<span id="cb3-79"></span>
<span id="cb3-80"><span class="ss" style="color: #20794D;
<span id="cb3-76"></span>
<span id="cb3-77"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Update specs first**: When changing behavior, update spec before</span>
<span id="cb3-81"> implementation</span>
<span id="cb3-82"><span class="ss" style="color: #20794D;
<span id="cb3-78"> implementation</span>
<span id="cb3-79"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Document changes**: Use clear commit messages explaining spec changes</span>
<span id="cb3-83"><span class="ss" style="color: #20794D;
<span id="cb3-80"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Review process**: Have specs reviewed before implementation</span>
<span id="cb3-84"></span>
<span id="cb3-85"><span class="fu" style="color: #4758AB;
<span id="cb3-81"></span>
<span id="cb3-82"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Consistency Checks</span></span>
<span id="cb3-86"></span>
<span id="cb3-87"><span class="ss" style="color: #20794D;
<span id="cb3-83"></span>
<span id="cb3-84"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Cross-reference validation**: Ensure all links to other specs are valid</span>
<span id="cb3-88"><span class="ss" style="color: #20794D;
<span id="cb3-85"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Terminology consistency**: Use consistent terms across all specs</span>
<span id="cb3-89"><span class="ss" style="color: #20794D;
<span id="cb3-86"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Format consistency**: Follow established formatting patterns</span>
<span id="cb3-90"></span>
<span id="cb3-91"><span class="fu" style="color: #4758AB;
<span id="cb3-87"></span>
<span id="cb3-88"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Testing Integration</span></span>
<span id="cb3-92"></span>
<span id="cb3-93"><span class="ss" style="color: #20794D;
<span id="cb3-89"></span>
<span id="cb3-90"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Spec-driven tests**: Write tests based on specification requirements</span>
<span id="cb3-94"><span class="ss" style="color: #20794D;
<span id="cb3-91"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Snapshot validation**: Ensure snapshots match specification exactly</span>
<span id="cb3-95"><span class="ss" style="color: #20794D;
<span id="cb3-92"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Approval tests**: Use approval tests to catch spec violations</span>
<span id="cb3-96"></span>
<span id="cb3-97"><span class="fu" style="color: #4758AB;
<span id="cb3-93"></span>
<span id="cb3-94"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">## Quality Checklist</span></span>
<span id="cb3-98"></span>
<span id="cb3-99"><span class="fu" style="color: #4758AB;
<span id="cb3-95"></span>
<span id="cb3-96"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Before Finalizing Specification</span></span>
<span id="cb3-100"></span>
<span id="cb3-101"><span class="ss" style="color: #20794D;
<span id="cb3-97"></span>
<span id="cb3-98"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> All requirements clearly stated</span>
<span id="cb3-102"><span class="ss" style="color: #20794D;
<span id="cb3-99"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Examples provided for complex requirements</span>
<span id="cb3-103"><span class="ss" style="color: #20794D;
<span id="cb3-100"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Error cases covered</span>
<span id="cb3-104"><span class="ss" style="color: #20794D;
<span id="cb3-101"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Cross-references to other specs included</span>
<span id="cb3-105"><span class="ss" style="color: #20794D;
<span id="cb3-102"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Out of scope items clearly defined</span>
<span id="cb3-106"><span class="ss" style="color: #20794D;
<span id="cb3-103"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Testing requirements specified</span>
<span id="cb3-107"><span class="ss" style="color: #20794D;
<span id="cb3-104"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Consistent formatting throughout</span>
<span id="cb3-108"><span class="ss" style="color: #20794D;
<span id="cb3-105"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Check the generated Document with <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`markdownlint`</span> (if available), apply</span>
<span id="cb3-109"> auto-fixes and fix the remaining issues manually.</span>
<span id="cb3-110"></span>
<span id="cb3-111"><span class="fu" style="color: #4758AB;
<span id="cb3-106"> auto-fixes and fix the remaining issues manually.</span>
<span id="cb3-107"></span>
<span id="cb3-108"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Review Criteria</span></span>
<span id="cb3-112"></span>
<span id="cb3-113"><span class="ss" style="color: #20794D;
<span id="cb3-109"></span>
<span id="cb3-110"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Is the specification unambiguous?</span>
<span id="cb3-114"><span class="ss" style="color: #20794D;
<span id="cb3-111"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Are all edge cases covered?</span>
<span id="cb3-115"><span class="ss" style="color: #20794D;
<span id="cb3-112"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Does it integrate well with other specs?</span>
<span id="cb3-116"><span class="ss" style="color: #20794D;
<span id="cb3-113"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Is it testable?</span>
<span id="cb3-117"><span class="ss" style="color: #20794D;
<span id="cb3-114"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">[ ]</span> Is it maintainable?</span>
<span id="cb3-118"></span>
<span id="cb3-119"><span class="fu" style="color: #4758AB;
<span id="cb3-115"></span>
<span id="cb3-116"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">## Common Pitfalls to Avoid</span></span>
<span id="cb3-120"></span>
<span id="cb3-121"><span class="fu" style="color: #4758AB;
<span id="cb3-117"></span>
<span id="cb3-118"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Ambiguity</span></span>
<span id="cb3-122"></span>
<span id="cb3-123"><span class="ss" style="color: #20794D;
<span id="cb3-119"></span>
<span id="cb3-120"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Vague language**: "The system should handle errors gracefully"</span>
<span id="cb3-124"><span class="ss" style="color: #20794D;
<span id="cb3-121"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Missing details**: Not specifying exact error handling behavior</span>
<span id="cb3-125"><span class="ss" style="color: #20794D;
<span id="cb3-122"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Unclear relationships**: Not explaining how components interact</span>
<span id="cb3-126"></span>
<span id="cb3-127"><span class="fu" style="color: #4758AB;
<span id="cb3-123"></span>
<span id="cb3-124"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Inconsistency</span></span>
<span id="cb3-128"></span>
<span id="cb3-129"><span class="ss" style="color: #20794D;
<span id="cb3-125"></span>
<span id="cb3-126"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Different terms**: Using different terms for the same concept</span>
<span id="cb3-130"><span class="ss" style="color: #20794D;
<span id="cb3-127"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Inconsistent formatting**: Not following established patterns</span>
<span id="cb3-131"><span class="ss" style="color: #20794D;
<span id="cb3-128"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Conflicting requirements**: Requirements that contradict other specs</span>
<span id="cb3-132"></span>
<span id="cb3-133"><span class="fu" style="color: #4758AB;
<span id="cb3-129"></span>
<span id="cb3-130"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Incompleteness</span></span>
<span id="cb3-134"></span>
<span id="cb3-135"><span class="ss" style="color: #20794D;
<span id="cb3-131"></span>
<span id="cb3-132"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Missing edge cases**: Not considering unusual scenarios</span>
<span id="cb3-136"><span class="ss" style="color: #20794D;
<span id="cb3-133"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Incomplete examples**: Examples that don't cover all cases</span>
<span id="cb3-137"><span class="ss" style="color: #20794D;
<span id="cb3-134"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>**Missing error handling**: Not specifying what happens when things go wrong</span>
<span id="cb3-138"></span>
<span id="cb3-139"><span class="fu" style="color: #4758AB;
<span id="cb3-135"></span>
<span id="cb3-136"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">## Related Rules</span></span>
<span id="cb3-140"></span>
<span id="cb3-141"><span class="ss" style="color: #20794D;
<span id="cb3-137"></span>
<span id="cb3-138"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="co" style="color: #5E5E5E;
background-color: null;
@ -666,8 +740,8 @@ background-color: null;
font-style: inherit;">spec-compliance-investigation.mdc</span><span class="co" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">](mdc:.cursor/rules/spec-compliance-investigation.mdc)</span></span>
<span id="cb3-142"> How to investigate spec-implementation discrepancies</span>
<span id="cb3-143"><span class="ss" style="color: #20794D;
<span id="cb3-139"> How to investigate spec-implementation discrepancies</span>
<span id="cb3-140"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span><span class="co" style="color: #5E5E5E;
background-color: null;
@ -676,7 +750,7 @@ background-color: null;
font-style: inherit;">base_overview.mdc</span><span class="co" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">](mdc:.cursor/rules/base_overview.mdc)</span> Project structure and</span>
<span id="cb3-144"> conventions</span></code></pre></div>
<span id="cb3-141"> conventions</span></code></pre></div>
</div>
<p>As it is obvious this is a very intricate rule with many criteria. For this you really <strong>need</strong> a reasoning and deep-thinking model that can also reason for extended times (many minutes are normal!) and call tools every now and then to get even more information. Models like <code>o3</code>, <code>deepseek-r1</code> and the <code>opus</code>-series of <code>claude</code> really shine here.</p>
</section>
@ -1054,24 +1128,37 @@ font-style: inherit;">### Purpose</span></span>
background-color: null;
font-style: inherit;">### Output</span></span>
<span id="cb5-15"></span>
<span id="cb5-16">• Create /tasks/<span class="dt" style="color: #AD0000;
<span id="cb5-16"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Create /tasks/<span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&lt;</span><span class="kw" style="color: #003B4F;
background-color: null;
font-weight: bold;
font-style: inherit;">feature</span><span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&gt;</span>/TASKS.md (overwrite if it exists). • Markdown only, no</span>
<span id="cb5-17">prose around it. • Epics = H2 headings (<span class="in" style="color: #5E5E5E;
font-style: inherit;">&gt;</span>/TASKS.md (overwrite if it exists).</span>
<span id="cb5-17"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">`## 1. &lt;Epic&gt;`</span>). • Tasks = unchecked</span>
<span id="cb5-18">check‑boxes (<span class="in" style="color: #5E5E5E;
font-style: inherit;">- </span>Markdown only, no prose around it.</span>
<span id="cb5-18"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">`- [ ] 1.1 &lt;task&gt;`</span>). • Sub‑tasks = indent one space under their</span>
<span id="cb5-19">parent (<span class="in" style="color: #5E5E5E;
font-style: inherit;">- </span>Epics = H2 headings (<span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">` - [ ] 1.1.1 &lt;subtask&gt;`</span>). • Create a</span>
<span id="cb5-20">/tasks/<span class="dt" style="color: #AD0000;
font-style: inherit;">`## 1. &lt;Epic&gt;`</span>).</span>
<span id="cb5-19"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Tasks = unchecked check‑boxes (<span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`- [ ] 1.1 &lt;task&gt;`</span>).</span>
<span id="cb5-20"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Sub‑tasks = indent one space under their parent (<span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">` - [ ] 1.1.1 &lt;subtask&gt;`</span>).</span>
<span id="cb5-21"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Create a /tasks/<span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&lt;</span><span class="kw" style="color: #003B4F;
background-color: null;
@ -1094,40 +1181,40 @@ background-color: null;
font-weight: bold;
font-style: inherit;">subtask</span><span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&gt;</span>.md (i.e. <span class="in" style="color: #5E5E5E;
font-style: inherit;">&gt;</span>.md (i.e.</span>
<span id="cb5-22"> <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`Task_3_2_4.md`</span> for Epic</span>
<span id="cb5-21">3, Task 2, Subtask 4)</span>
<span id="cb5-22"></span>
<span id="cb5-23"><span class="fu" style="color: #4758AB;
font-style: inherit;">`Task_3_2_4.md`</span> for Epic 3, Task 2, Subtask 4)</span>
<span id="cb5-23"></span>
<span id="cb5-24"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Process</span></span>
<span id="cb5-24"></span>
<span id="cb5-25"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">1. </span>Read the tagged PRD.</span>
<span id="cb5-25"></span>
<span id="cb5-26"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">1. </span>Read the tagged PRD.</span>
<span id="cb5-27"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">2. </span>**Investigate** the current state of the repository to collect answers to</span>
<span id="cb5-27"> your first questions. All specs for fixed behaviours and outputs are located</span>
<span id="cb5-28"> in <span class="in" style="color: #5E5E5E;
<span id="cb5-28"> your first questions. All specs for fixed behaviours and outputs are located</span>
<span id="cb5-29"> in <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`specs/`</span>. **Consult those** as a source first before trying to</span>
<span id="cb5-29"> reverse-engineer from the code. </span>
<span id="cb5-30"> If specs are in need of change then this is also a task to be generated.</span>
<span id="cb5-31"><span class="ss" style="color: #20794D;
<span id="cb5-30"> reverse-engineer from the code. </span>
<span id="cb5-31"> If specs are in need of change then this is also a task to be generated.</span>
<span id="cb5-32"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">3. </span>If critical info is missing and cannot be answered by looking at the code,</span>
<span id="cb5-32"> ask max five clarifying questions (Q1 … Q5) and stop until answered.</span>
<span id="cb5-33"><span class="ss" style="color: #20794D;
<span id="cb5-33"> ask max five clarifying questions (Q1 … Q5) and stop until answered.</span>
<span id="cb5-34"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">4. </span>After questions are answered think about the answers and: Either: look at the</span>
<span id="cb5-34"> code again, then goto 3., and ask for further clarification Or: Reply</span>
<span id="cb5-35"> exactly: Ready to generate the subtasks – respond **go** to proceed.</span>
<span id="cb5-36"><span class="ss" style="color: #20794D;
<span id="cb5-35"> code again, then goto 3., and ask for further clarification Or: Reply</span>
<span id="cb5-36"> exactly: Ready to generate the subtasks – respond **go** to proceed.</span>
<span id="cb5-37"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">5. </span>On a user message that contains only the word "go" (case‑insensitive): a.</span>
<span id="cb5-37"> Generate /tasks/<span class="dt" style="color: #AD0000;
<span id="cb5-38"> Generate /tasks/<span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&lt;</span><span class="kw" style="color: #003B4F;
background-color: null;
@ -1135,40 +1222,62 @@ font-weight: bold;
font-style: inherit;">feature</span><span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">&gt;</span>/TASKS.md following _Output_ spec. b. Reply with:</span>
<span id="cb5-38"> TASKS.md created – review them.</span>
<span id="cb5-39"><span class="ss" style="color: #20794D;
<span id="cb5-39"> TASKS.md created – review them.</span>
<span id="cb5-40"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">6. </span>After TASKS.md was reviewed, create <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`Task_&lt;e&gt;_&lt;t&gt;_&lt;s&gt;.md`</span> for each task and</span>
<span id="cb5-40"> subtask containing implementation hints like relevant specs (link them!),</span>
<span id="cb5-41"> primary files to edit/review for this task, tests needing change, etc.</span>
<span id="cb5-42"><span class="ss" style="color: #20794D;
<span id="cb5-41"> subtask containing implementation hints like relevant specs (link them!),</span>
<span id="cb5-42"> primary files to edit/review for this task, tests needing change, etc.</span>
<span id="cb5-43"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">7. </span>Stop. Do **not** begin executing tasks in this rule.</span>
<span id="cb5-43"></span>
<span id="cb5-44"><span class="fu" style="color: #4758AB;
<span id="cb5-44"></span>
<span id="cb5-45"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Writing guidelines</span></span>
<span id="cb5-45"></span>
<span id="cb5-46">• Each item ≤120 characters, start with an action verb. • Hints are allowed</span>
<span id="cb5-47">below each item as HTML-Comment and do not count against the 120 characters. •</span>
<span id="cb5-48">Group related work into logical epics with ≤7 direct child items. • Prefer</span>
<span id="cb5-49">concrete file paths, commands, specs or APIs when available. • Skip</span>
<span id="cb5-50">implementation details obvious from the codebase in the overview. • If a task</span>
<span id="cb5-51">only concerns up to 5 files, name them in the detailed file. Otherwise give</span>
<span id="cb5-52">hints on how to search for them (i.e. "everything under src/models/").</span>
<span id="cb5-53"></span>
<span id="cb5-54"><span class="fu" style="color: #4758AB;
<span id="cb5-46"></span>
<span id="cb5-47"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Each item ≤120 characters, start with an action verb.</span>
<span id="cb5-48"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Hints are allowed below each item as HTML-Comment and do not count against the</span>
<span id="cb5-49"> 120 characters.</span>
<span id="cb5-50"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Group related work into logical epics with ≤7 direct child items.</span>
<span id="cb5-51"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Prefer concrete file paths, commands, specs or APIs when available.</span>
<span id="cb5-52"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Skip implementation details obvious from the codebase in the overview.</span>
<span id="cb5-53"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>If a task only concerns up to 5 files, name them in the detailed file.</span>
<span id="cb5-54"> Otherwise give hints on how to search for them (i.e. "everything under</span>
<span id="cb5-55"> <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`src/models/`</span>").</span>
<span id="cb5-56"></span>
<span id="cb5-57"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">### Safety rails</span></span>
<span id="cb5-55"></span>
<span id="cb5-56">• Never touch production data. • Assume all work happens in a feature branch,</span>
<span id="cb5-57">never commit directly to main. • Check the generated Document with</span>
<span id="cb5-58"><span class="in" style="color: #5E5E5E;
<span id="cb5-58"></span>
<span id="cb5-59"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">`markdownlint`</span> (if available), apply auto-fixes and fix the remaining issues</span>
<span id="cb5-59">manually.</span></code></pre></div>
font-style: inherit;">- </span>Never touch production data.</span>
<span id="cb5-60"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Assume all work happens in a feature branch, never commit directly to main.</span>
<span id="cb5-61"><span class="ss" style="color: #20794D;
background-color: null;
font-style: inherit;">- </span>Check the generated Document with <span class="in" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">`markdownlint`</span> (if available), apply</span>
<span id="cb5-62"> auto-fixes and fix the remaining issues manually.</span></code></pre></div>
</div>
<p>This also works better with one of those deep-thinking models.</p>
</section>
@ -1180,7 +1289,7 @@ font-style: inherit;">`markdownlint`</span> (if available), apply auto-fixes and
</section>
<section id="example-rules-in-action" class="level2 page-columns page-full">
<h2 class="anchored" data-anchor-id="example-rules-in-action">Example: Rules in Action</h2>
<p>The codebase we look at here is a project called <code>gitlab_overviewer</code>. It takes gitlab-api-keys and generates nice overviews for tracking metadata in different projects across different groups. With a nice export to markdown (for rendering in gitlab itself) and quarto (for exporting to i.e.&nbsp;confluence) with multiple pages etc. pp.</p>
<p>The codebase we look at here is a project called <code>gitlab_overviewer</code>. It takes GitLab-api-keys and generates nice overviews for tracking metadata in different projects across different groups. With a nice export to markdown (for rendering in GitLab itself) and quarto (for exporting to i.e.&nbsp;confluence) with multiple pages etc. pp.</p>
<p>The current issue is, that due to a complete rewrite we are happy with the current output, but there are some minor problems still remaining. Some of them may also due to specs being incorrect, because requirements or ideas changed over time.</p>
<section id="analyzing-the-situation" class="level3 page-columns page-full">
<h3 class="anchored">Analyzing the situation</h3>
@ -1725,7 +1834,7 @@ font-style: inherit;">`&lt;web_url&gt;/-/releases`</span>. // ...</span>
<li><strong>Project Integrity</strong>: Through rigorous spec adherence and systematic task breakdown, the codebase is more consistent, much better documented and decently tested<sup>5</sup>.</li>
<li><strong>Reduced Cognitive Load</strong>: The Cursor rule system has made it easier to focus on actual development tasks instead of wrestling with the AI’s sometimes questionable assumptions - or just installing a third different testing framework for exactly this module.</li>
</ul>
<div class="no-row-height column-margin column-container"><div id="fn5"><p><sup>5</sup>&nbsp;You know.. noone likes writing tests - and the person writing the code should never write the tests anyway. If you haven’t thought of something while coding, chanches are, that you miss that edge-case during testing as well.</p></div></div><p>In this <code>gitlab_overviewer</code> case study, i tried to show at an easy example, that this method works and <em>can</em> yields great outcomes. Even small discrepancies in the codebase tend to pop up during spec-reviews (which can be automated!). Next up would be running those in some kind of CI-job and integrating tools like issue-tracking into the agent instead of simple markdown-files in the repository as makeshift issue-tracker. But not by me for the forseeable future, so if you are looking for a project, feel free!</p>
<div class="no-row-height column-margin column-container"><div id="fn5"><p><sup>5</sup>&nbsp;You know.. noone likes writing tests - and the person writing the code should never write the tests anyway. If you haven’t thought of something while coding, chanches are, that you miss that edge-case during testing as well.</p></div></div><p>In this <code>gitlab_overviewer</code> case study, i tried to show at an easy example, that this method works and <em>can</em> yields great outcomes. Even small discrepancies in the codebase tend to pop up during spec-reviews (which can be automated!). Next up would be running those in some kind of CI-job and integrating tools like issue-tracking into the agent instead of simple markdown-files in the repository as makeshift issue-tracker. But not by me for the foreseeable future, so if you are looking for a project, feel free!</p>
<p><strong>All in all this isn’t a silver bullet for all AI-assisted development problems, but it’s made my coding experience with Cursor much more productive and predictable. It turns out treating an AI as a slightly overeager junior developer who needs clear instructions works better than hoping it’ll just “do the right thing”.</strong></p>
@ -6263,7 +6372,6 @@ background-color: null;
font-style: inherit;">&lt;&gt;</span> <span class="st" style="color: #20794D;
background-color: null;
font-style: inherit;">"\n"</span></span></code></pre></div>
{{&lt; dend &gt;}}
</blockquote></details></section>
<section id="weitere-instanzen-und-definitionen-die-der-generator-noch-nicht-macht" class="level4">
<h4 class="anchored" data-anchor-id="weitere-instanzen-und-definitionen-die-der-generator-noch-nicht-macht">Weitere Instanzen und Definitionen, die der Generator (noch) nicht macht</h4>
@ -6681,7 +6789,6 @@ background-color: null;
font-style: inherit;">Repsonse</span> <span class="co" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">-- FromBSON-Instanz geht immer davon aus, dass alle keys da sind (ggf. mit null bei Nothing).</span></span></code></pre></div>
{{&lt; dend &gt;}}
</blockquote></details></section>
<section id="was-noch-zu-tun-ist" class="level4">
<h4 class="anchored" data-anchor-id="was-noch-zu-tun-ist">Was noch zu tun ist</h4>
@ -6974,50 +7081,6 @@ font-style: inherit;">--interleaved-output</span></span></code></pre></div>
<guid>https://drezil.de/Health/Issues.html</guid>
<pubDate>Mon, 31 Dec 2018 23:00:00 GMT</pubDate>
</item>
<item>
<title>Fortgeschrittene funktionale Programmierung in Haskell</title>
<link>https://drezil.de/Coding/Haskell/FFPiH.html</link>
<description><![CDATA[
<p>FFPiH ist eine Vorlesung, die ich zusammen mit einem Kommilitonen im Sommer 2015 erstmals erstellt und gehalten haben.</p>
<p>Insgesamt haben wir die Vorlesung 3x gehalten, wobei von der ersten zur zweiten Iteration der Inhalt massiv überarbeitet wurde und bei der Iteration von der zweiten zur dritten Vorlesung die Übungen komplett neu erstellt wurden.</p>
<p>Die gesamten Übungen sind unter anderem in der FFPiH-Organisation in meinem gitea hinterlegt: <a href="https://gitea.dresselhaus.cloud/FFPiH">https://gitea.dresselhaus.cloud/FFPiH</a></p>
<p>Einige der aktualisierten Übungen sind privat geschaltet, da diese iterativ aufeinander aufbauen und jeweils die Musterlösung der vorherigen enthalten.</p>
<section id="aufbau-der-vorlesung" class="level2">
<h2 class="anchored" data-anchor-id="aufbau-der-vorlesung">Aufbau der Vorlesung</h2>
<p>Vorausgesetzt wurde, dass die Studierenden das erste Semester abgeschlossen hatten und somit bereits leichte Grundlagen in Haskell kannten (aber z.b. Dinge wie Functor/Applicative/Monad noch nicht <em>wirklich</em> erklärt bekommen haben).</p>
<p>Stück für Stück werden die Studis dann zunächst in abstrakte Konstrukte eingeführt, aber diese werden dann schnell in die Praxis umgesetzt. Etwa mit dem Schreiben eines eigenen Parsers.</p>
<p>Schlussendlich gibt es dann einen “Rundumschlag” durch die gesamte Informatik. Erstellung eines Spieles (auf basis einer kleinen Grundlage), erstellung von WebApps mit Yesod, Parallelisierung und Nebenläufigkeit für rechenintensive Anwendungen inkl. synchronisation mittels STM.</p>
<p>Optional gab es weitere Übungen zu dingen wie “verteiltes Rechnen”.</p>
<p>Ziel hierbei war nicht, diese ganzen Themen in der Tiefe beizubringen, sondern aufzuzeigen, wie sie sehr schnell abstrakte Konstrukte, die ihnen ggf. 3 Semester später erst begegnen bugfrei benutzen können, da Haskell hier in sehr vielen Fällen einfach nur die “richtige” Lösung kompilieren lässt und alle gängigen Fallen schlicht ausschließt. Beispiel ist z.b. STM innerhalb von STM, Mischen von DB-Monade, Handler-Monade und Template-Engine in Yesod, Process () statt IO () in der Nutzung von CloudHaskell, etc. pp.</p>
</section>
<section id="studentisches-feedback" class="level2">
<h2 class="anchored" data-anchor-id="studentisches-feedback">Studentisches Feedback</h2>
<p>Sehr gutes Feedback von den Studenten bekamen wir insbesondere für Übungen wie:</p>
<p><a href="https://gitea.dresselhaus.cloud/FFPiH/uebung2017_2/src/branch/master/src/Aufgabe2.hs">Übung 2, Aufgabe 2</a>, weil hier durch “einfaches” umformen hin zu Abstraktionen und mit den Regeln dieser im ersten Fall die Laufzeit (vor Compileroptimierungen) von O(n²) auf O(0) ändert.</p>
<p><a href="https://gitea.dresselhaus.cloud/FFPiH/uebung2017-4">Übung 4</a>, welche ein komplett fertigen (sehr rudimentären und simplen) Dungeon-Crawler bereitstellt, der “nur” 1-2 bugs hat und “wie ein echtes Projekt” erweitert werden muss. Diese Übung hat sich dann über 4 weitere Übungen gestreckt, wobei folgende Aufgaben gelöst werden müssen:</p>
<ul>
<li>Einarbeitung in QuickCheck zur Behebung eines Bugs im Test</li>
<li>Umschreiben von explizitem Argument-Passing hin zu Monad-Transformers mit stateful <a href="../../Coding/Haskell/Lenses.html">Lenses</a></li>
<li>Continuation-Basierendes Event-System</li>
<li>Hinzufügen eines Parsers für Level, Items &amp; deren Effekte und implementation dieser</li>
<li>Ändern des GUI-Parts von CLI auf 2D GL mittels gloss</li>
<li>Ändern von <code>StateT World</code> auf <code>RWST GameConfig Log World</code> und somit nutzen von individuellen Konfigurationen für z.b. Keybindings</li>
</ul>
</section>
]]></description>
<category>Lecture</category>
<category>Haskell</category>
<guid>https://drezil.de/Coding/Haskell/FFPiH.html</guid>
<pubDate>Sun, 31 Dec 2017 23:00:00 GMT</pubDate>
</item>
<item>
<title>Lenses</title>
<link>https://drezil.de/Coding/Haskell/Lenses.html</link>
@ -8840,6 +8903,50 @@ font-style: inherit;">-&gt;</span> f t</span></code></pre></div>
<guid>https://drezil.de/Coding/Haskell/Lenses.html</guid>
<pubDate>Sun, 31 Dec 2017 23:00:00 GMT</pubDate>
</item>
<item>
<title>Fortgeschrittene funktionale Programmierung in Haskell</title>
<link>https://drezil.de/Coding/Haskell/FFPiH.html</link>
<description><![CDATA[
<p>FFPiH ist eine Vorlesung, die ich zusammen mit einem Kommilitonen im Sommer 2015 erstmals erstellt und gehalten haben.</p>
<p>Insgesamt haben wir die Vorlesung 3x gehalten, wobei von der ersten zur zweiten Iteration der Inhalt massiv überarbeitet wurde und bei der Iteration von der zweiten zur dritten Vorlesung die Übungen komplett neu erstellt wurden.</p>
<p>Die gesamten Übungen sind unter anderem in der FFPiH-Organisation in meinem gitea hinterlegt: <a href="https://gitea.dresselhaus.cloud/FFPiH">https://gitea.dresselhaus.cloud/FFPiH</a></p>
<p>Einige der aktualisierten Übungen sind privat geschaltet, da diese iterativ aufeinander aufbauen und jeweils die Musterlösung der vorherigen enthalten.</p>
<section id="aufbau-der-vorlesung" class="level2">
<h2 class="anchored" data-anchor-id="aufbau-der-vorlesung">Aufbau der Vorlesung</h2>
<p>Vorausgesetzt wurde, dass die Studierenden das erste Semester abgeschlossen hatten und somit bereits leichte Grundlagen in Haskell kannten (aber z.b. Dinge wie Functor/Applicative/Monad noch nicht <em>wirklich</em> erklärt bekommen haben).</p>
<p>Stück für Stück werden die Studis dann zunächst in abstrakte Konstrukte eingeführt, aber diese werden dann schnell in die Praxis umgesetzt. Etwa mit dem Schreiben eines eigenen Parsers.</p>
<p>Schlussendlich gibt es dann einen “Rundumschlag” durch die gesamte Informatik. Erstellung eines Spieles (auf basis einer kleinen Grundlage), erstellung von WebApps mit Yesod, Parallelisierung und Nebenläufigkeit für rechenintensive Anwendungen inkl. synchronisation mittels STM.</p>
<p>Optional gab es weitere Übungen zu dingen wie “verteiltes Rechnen”.</p>
<p>Ziel hierbei war nicht, diese ganzen Themen in der Tiefe beizubringen, sondern aufzuzeigen, wie sie sehr schnell abstrakte Konstrukte, die ihnen ggf. 3 Semester später erst begegnen bugfrei benutzen können, da Haskell hier in sehr vielen Fällen einfach nur die “richtige” Lösung kompilieren lässt und alle gängigen Fallen schlicht ausschließt. Beispiel ist z.b. STM innerhalb von STM, Mischen von DB-Monade, Handler-Monade und Template-Engine in Yesod, Process () statt IO () in der Nutzung von CloudHaskell, etc. pp.</p>
</section>
<section id="studentisches-feedback" class="level2">
<h2 class="anchored" data-anchor-id="studentisches-feedback">Studentisches Feedback</h2>
<p>Sehr gutes Feedback von den Studenten bekamen wir insbesondere für Übungen wie:</p>
<p><a href="https://gitea.dresselhaus.cloud/FFPiH/uebung2017_2/src/branch/master/src/Aufgabe2.hs">Übung 2, Aufgabe 2</a>, weil hier durch “einfaches” umformen hin zu Abstraktionen und mit den Regeln dieser im ersten Fall die Laufzeit (vor Compileroptimierungen) von O(n²) auf O(0) ändert.</p>
<p><a href="https://gitea.dresselhaus.cloud/FFPiH/uebung2017-4">Übung 4</a>, welche ein komplett fertigen (sehr rudimentären und simplen) Dungeon-Crawler bereitstellt, der “nur” 1-2 bugs hat und “wie ein echtes Projekt” erweitert werden muss. Diese Übung hat sich dann über 4 weitere Übungen gestreckt, wobei folgende Aufgaben gelöst werden müssen:</p>
<ul>
<li>Einarbeitung in QuickCheck zur Behebung eines Bugs im Test</li>
<li>Umschreiben von explizitem Argument-Passing hin zu Monad-Transformers mit stateful <a href="../../Coding/Haskell/Lenses.html">Lenses</a></li>
<li>Continuation-Basierendes Event-System</li>
<li>Hinzufügen eines Parsers für Level, Items &amp; deren Effekte und implementation dieser</li>
<li>Ändern des GUI-Parts von CLI auf 2D GL mittels gloss</li>
<li>Ändern von <code>StateT World</code> auf <code>RWST GameConfig Log World</code> und somit nutzen von individuellen Konfigurationen für z.b. Keybindings</li>
</ul>
</section>
]]></description>
<category>Lecture</category>
<category>Haskell</category>
<guid>https://drezil.de/Coding/Haskell/FFPiH.html</guid>
<pubDate>Sun, 31 Dec 2017 23:00:00 GMT</pubDate>
</item>
<item>
<title>Monoid? Da war doch was…</title>
<link>https://drezil.de/Coding/Haskell/Code Snippets/Monoid.html</link>

2
dist/listings.json vendored
View File

@ -11,8 +11,8 @@
"/Coding/Haskell/Webapp-Example/MyService_Types.hs.html",
"/Coding/Haskell/Webapp-Example/index.html",
"/Health/Issues.html",
"/Coding/Haskell/FFPiH.html",
"/Coding/Haskell/Lenses.html",
"/Coding/Haskell/FFPiH.html",
"/Coding/Haskell/Code Snippets/Monoid.html",
"/Coding/Haskell/Code Snippets/Morphisms.html",
"/Coding/Haskell/Advantages.html",

946
dist/search.json vendored
View File

File diff suppressed because one or more lines are too long

24
dist/sitemap.xml vendored
View File

@ -2,15 +2,15 @@
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://drezil.de/index.html</loc>
<lastmod>2025-06-13T08:17:37.525Z</lastmod>
<lastmod>2025-06-29T11:34:03.232Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Writing/Obsidian-RAG.html</loc>
<lastmod>2025-05-09T19:08:56.279Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Writing/documentation.html</loc>
<lastmod>2025-06-05T17:18:21.768Z</lastmod>
<loc>https://drezil.de/Writing/coding-age-ai.html</loc>
<lastmod>2025-06-29T11:46:03.135Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Uni/Lernerfolg_an_der_Uni.html</loc>
@ -21,12 +21,12 @@
<lastmod>2025-05-09T18:31:10.026Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Coding/Haskell/Advantages.html</loc>
<lastmod>2025-05-09T07:11:06.603Z</lastmod>
<loc>https://drezil.de/Coding/Haskell/FFPiH.html</loc>
<lastmod>2025-06-29T11:35:04.263Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Coding/Haskell/FFPiH.html</loc>
<lastmod>2025-05-09T07:07:51.739Z</lastmod>
<loc>https://drezil.de/Coding/Haskell/Lenses.html</loc>
<lastmod>2025-05-09T07:10:26.159Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Coding/Haskell/Webapp-Example/MyService_Types.hs.html</loc>
@ -62,11 +62,11 @@
</url>
<url>
<loc>https://drezil.de/Coding/Haskell/Webapp-Example/index.html</loc>
<lastmod>2025-05-09T19:20:12.478Z</lastmod>
<lastmod>2025-06-29T11:30:44.156Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Coding/Haskell/Lenses.html</loc>
<lastmod>2025-05-09T07:10:26.159Z</lastmod>
<loc>https://drezil.de/Coding/Haskell/Advantages.html</loc>
<lastmod>2025-05-09T07:11:06.603Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Health/Issues.html</loc>
@ -85,8 +85,8 @@
<lastmod>2025-06-05T13:06:32.542Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Writing/coding-age-ai.html</loc>
<lastmod>2025-06-26T21:04:58.361Z</lastmod>
<loc>https://drezil.de/Writing/documentation.html</loc>
<lastmod>2025-06-05T17:18:21.768Z</lastmod>
</url>
<url>
<loc>https://drezil.de/Obsidian-Articles/Artikelbewertung durch LLM.html</loc>

BIN
dist/thumbs/assets_task_01jyq0b0wtewyr9wthgg6e8agt_1750971350_img_0.webp vendored
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 37 KiB

4
index.qmd
View File

@ -20,6 +20,10 @@ listing:
format:
html:
other-links:
- text: Gitea
icon: cup-hot-fill
href: "https://gitea.dresselhaus.cloud/Drezil"
rel: me
- text: Mastodon
icon: mastodon
href: "https://toot.kif.rocks/@Drezil"