@dzhechkov/keysarium 1.5.36 → 1.5.38

package/templates/.claude/skills/feature-adr/modules/01-requirements.md

@@ -77,6 +77,32 @@ Explicitly state:
 - **Dependencies:** What must exist before this feature works
 - **Dependents:** What will break if this feature changes
 
+## Write discipline (the 180-second rule)
+
+An executor that returns from a tool call and then thinks in silence past **180 seconds** is killed by the
+runtime. Thinking time grows with the history already accumulated, so on a large repo "read everything,
+then write the document" is not a risk — it is a deterministic death, and nothing survives it, because
+nothing was ever on disk.
+
+MEASURED on this harness: the writing steps died **18 times out of 18** in the reading phase without ever
+writing a file. The control — same slice, same model, one added instruction to write a skeleton early —
+landed the skeleton 8 minutes in, on the first attempt, after six consecutive deaths.
+
+So, in this step:
+
+1. **Skeleton first — inside your first ~12 tool calls.** Write `features/<slug>/01_requirements.md` containing only the headings this step
+   requires (Stakeholders · Functional requirements · Non-functional requirements · Constraints ·
+   Scope boundaries · Open questions), one line of intent under each. (S-tier is inline and has no
+   file — this section does not apply to it.)
+2. **Then fill it one section per edit.** No single edit longer than ~120 lines. Every edit leaves the
+   file readable; none of them is allowed to wait for the section after it.
+3. **Never go more than 2 minutes without a tool call.** A thought that is getting long is the signal to
+   stop and write what you have — an edit is a checkpoint, not an interruption.
+4. **When you are unsure whether to read more or to write, WRITE.** A thin section refined later survives;
+   a perfect section you never reached does not.
+
+The skeleton is not a draft to apologise for. It is the artifact, opened early.
+
 ## Output
 
 ### For S-tier (inline)

package/templates/.claude/skills/feature-adr/modules/02-research.md

@@ -73,6 +73,32 @@ Alternative considered: [Y], rejected because [reasons].
 
 After both complete, synthesize results sequentially.
 
+## Write discipline (the 180-second rule)
+
+An executor that returns from a tool call and then thinks in silence past **180 seconds** is killed by the
+runtime. Thinking time grows with the history already accumulated, so on a large repo "read everything,
+then write the document" is not a risk — it is a deterministic death, and nothing survives it, because
+nothing was ever on disk.
+
+MEASURED on this harness: the writing steps died **18 times out of 18** in the reading phase without ever
+writing a file. The control — same slice, same model, one added instruction to write a skeleton early —
+landed the skeleton 8 minutes in, on the first attempt, after six consecutive deaths.
+
+So, in this step:
+
+1. **Skeleton first — inside your first ~12 tool calls.** Write `features/<slug>/02_research.md` containing only the headings this step
+   requires (Codebase patterns · External patterns · Library evaluation · Anti-patterns ·
+   Recommended approach), one line of intent under each — before the research agents report back,
+   not after.
+2. **Then fill it one section per edit.** No single edit longer than ~120 lines. Every edit leaves the
+   file readable; none of them is allowed to wait for the section after it.
+3. **Never go more than 2 minutes without a tool call.** A thought that is getting long is the signal to
+   stop and write what you have — an edit is a checkpoint, not an interruption.
+4. **When you are unsure whether to read more or to write, WRITE.** A thin section refined later survives;
+   a perfect section you never reached does not.
+
+The skeleton is not a draft to apologise for. It is the artifact, opened early.
+
 ## Output
 
 Create `features/<slug>/02_research.md` with:

package/templates/.claude/skills/feature-adr/modules/03-adr.md

@@ -167,6 +167,32 @@ Each ADR must trace back to specific requirements:
 | Placeholder text | Template hints or TODOs remain | Remove or fill before checkpoint |
 | Supersession in-place | Existing ADR rewritten | Mint a new ADR and link it |
 
+## Write discipline (the 180-second rule)
+
+An executor that returns from a tool call and then thinks in silence past **180 seconds** is killed by the
+runtime. Thinking time grows with the history already accumulated, so on a large repo "read everything,
+then write the document" is not a risk — it is a deterministic death, and nothing survives it, because
+nothing was ever on disk.
+
+MEASURED on this harness: the writing steps died **18 times out of 18** in the reading phase without ever
+writing a file. The control — same slice, same model, one added instruction to write a skeleton early —
+landed the skeleton 8 minutes in, on the first attempt, after six consecutive deaths.
+
+So, in this step:
+
+1. **Skeleton first — inside your first ~12 tool calls.** For each decision you have identified, write
+   `features/<slug>/03_adr/NNN-{decision-slug}.md` containing only the invariant-core headings
+   (Status · Context · Decision Drivers · Considered Options · Decision · Rationale · Consequences ·
+   Confirmation), one line of intent under each. A named-but-empty option beats an unwritten ADR.
+2. **Then fill it one section per edit.** No single edit longer than ~120 lines. Every edit leaves the
+   file readable; none of them is allowed to wait for the section after it.
+3. **Never go more than 2 minutes without a tool call.** A thought that is getting long is the signal to
+   stop and write what you have — an edit is a checkpoint, not an interruption.
+4. **When you are unsure whether to read more or to write, WRITE.** A thin section refined later survives;
+   a perfect section you never reached does not.
+
+The skeleton is not a draft to apologise for. It is the artifact, opened early.
+
 ## Output
 
 Create `features/<slug>/03_adr/` directory with:

package/templates/.claude/skills/feature-adr/modules/03.5-ideation-swarm.md

@@ -154,6 +154,31 @@ AM-N (source): <change>. Confirmation: <property> → test `test_name` (fails if
   an existence test and never fires in production.
 - A cheap lint holds the shape: every `AM-N` line must contain a `→ test ` token naming a test that exists.
 
+## Write discipline (the 180-second rule)
+
+An executor that returns from a tool call and then thinks in silence past **180 seconds** is killed by the
+runtime. Thinking time grows with the history already accumulated, so on a large repo "read everything,
+then write the document" is not a risk — it is a deterministic death, and nothing survives it, because
+nothing was ever on disk.
+
+MEASURED on this harness: the writing steps died **18 times out of 18** in the reading phase without ever
+writing a file. The control — same slice, same model, one added instruction to write a skeleton early —
+landed the skeleton 8 minutes in, on the first attempt, after six consecutive deaths.
+
+So, in this step:
+
+1. **Skeleton first — inside your first ~12 tool calls.** Write `features/<slug>/03.5_ideation_report.md` containing only the eight
+   section headings of §5 (Executive summary … Amendments), one line of intent under each — while
+   the swarm is still running, not after every agent has returned.
+2. **Then fill it one section per edit.** No single edit longer than ~120 lines. Every edit leaves the
+   file readable; none of them is allowed to wait for the section after it.
+3. **Never go more than 2 minutes without a tool call.** A thought that is getting long is the signal to
+   stop and write what you have — an edit is a checkpoint, not an interruption.
+4. **When you are unsure whether to read more or to write, WRITE.** A thin section refined later survives;
+   a perfect section you never reached does not.
+
+The skeleton is not a draft to apologise for. It is the artifact, opened early.
+
 ## Output
 
 Create `features/<slug>/03.5_ideation_report.md` with full QCSD report.

package/templates/.claude/skills/feature-adr/modules/04-ddd.md

@@ -92,6 +92,31 @@ Check that proposed domain model is compatible with existing code:
 - Can aggregates be implemented with existing ORM/framework?
 - Do relationships align with existing data access patterns?
 
+## Write discipline (the 180-second rule)
+
+An executor that returns from a tool call and then thinks in silence past **180 seconds** is killed by the
+runtime. Thinking time grows with the history already accumulated, so on a large repo "read everything,
+then write the document" is not a risk — it is a deterministic death, and nothing survives it, because
+nothing was ever on disk.
+
+MEASURED on this harness: the writing steps died **18 times out of 18** in the reading phase without ever
+writing a file. The control — same slice, same model, one added instruction to write a skeleton early —
+landed the skeleton 8 minutes in, on the first attempt, after six consecutive deaths.
+
+So, in this step:
+
+1. **Skeleton first — inside your first ~12 tool calls.** Write `features/<slug>/04_domain_model.md` containing only the headings this step
+   requires (Bounded context map · Ubiquitous language · Aggregates/Entities/VOs · Relationships ·
+   Codebase mapping), one line of intent under each.
+2. **Then fill it one section per edit.** No single edit longer than ~120 lines. Every edit leaves the
+   file readable; none of them is allowed to wait for the section after it.
+3. **Never go more than 2 minutes without a tool call.** A thought that is getting long is the signal to
+   stop and write what you have — an edit is a checkpoint, not an interruption.
+4. **When you are unsure whether to read more or to write, WRITE.** A thin section refined later survives;
+   a perfect section you never reached does not.
+
+The skeleton is not a draft to apologise for. It is the artifact, opened early.
+
 ## Output
 
 Create `features/<slug>/04_domain_model.md` with:

package/templates/.claude/skills/feature-adr/modules/05-architecture.md

@@ -118,6 +118,32 @@ GET /api/v1/{resource}/:id
   Errors: 401, 404
 ```
 
+## Write discipline (the 180-second rule)
+
+An executor that returns from a tool call and then thinks in silence past **180 seconds** is killed by the
+runtime. Thinking time grows with the history already accumulated, so on a large repo "read everything,
+then write the document" is not a risk — it is a deterministic death, and nothing survives it, because
+nothing was ever on disk.
+
+MEASURED on this harness: the writing steps died **18 times out of 18** in the reading phase without ever
+writing a file. The control — same slice, same model, one added instruction to write a skeleton early —
+landed the skeleton 8 minutes in, on the first attempt, after six consecutive deaths.
+
+So, in this step:
+
+1. **Skeleton first — inside your first ~12 tool calls.** Write `features/<slug>/05_architecture.md` containing only the headings this step
+   requires at your tier (C4 Context · C4 Container · C4 Component · Sequence flows · Data & storage ·
+   API design), one line of intent under each. An empty `mermaid` fence with a caption is a
+   heading; fill it later.
+2. **Then fill it one section per edit.** No single edit longer than ~120 lines. Every edit leaves the
+   file readable; none of them is allowed to wait for the section after it.
+3. **Never go more than 2 minutes without a tool call.** A thought that is getting long is the signal to
+   stop and write what you have — an edit is a checkpoint, not an interruption.
+4. **When you are unsure whether to read more or to write, WRITE.** A thin section refined later survives;
+   a perfect section you never reached does not.
+
+The skeleton is not a draft to apologise for. It is the artifact, opened early.
+
 ## Output
 
 ### M-tier

package/templates/.claude/skills/feature-adr/modules/06-implementation-plan.md

@@ -4,8 +4,11 @@
 
 ## When
 
-Always runs. Adapts depth by tier:
-- **S:** Inline checklist (3-5 items, no file)
+Always runs, and ALWAYS writes `features/<slug>/06_implementation_plan.md` — every tier. Depth adapts:
+- **S:** minimal plan FILE (3-5 tasks + an `EXPECTED_CODE_TARGETS:` block). An inline-only checklist is
+  no longer permitted: the K2 gate below is mandatory at every tier and it reads the file, so a plan
+  that exists only in the conversation makes the gate answer NOT-ESTABLISHED and the run stops. The
+  file must clear the gate's own floor: >200 characters and a non-empty targets block.
 - **M/L/XL:** Full structured plan document
 
 ## Model
@@ -132,15 +135,45 @@ Before finalizing the plan, validate completeness:
 
 This gap-check loop ensures the implementation plan is complete before coding begins.
 
+## Write discipline (the 180-second rule)
+
+An executor that returns from a tool call and then thinks in silence past **180 seconds** is killed by the
+runtime. Thinking time grows with the history already accumulated, so on a large repo "read everything,
+then write the document" is not a risk — it is a deterministic death, and nothing survives it, because
+nothing was ever on disk.
+
+MEASURED on this harness: the writing steps died **18 times out of 18** in the reading phase without ever
+writing a file. The control — same slice, same model, one added instruction to write a skeleton early —
+landed the skeleton 8 minutes in, on the first attempt, after six consecutive deaths.
+
+So, in this step:
+
+1. **Skeleton first — inside your first ~12 tool calls.** Write `features/<slug>/06_implementation_plan.md` containing only the headings
+   this step requires (Goal state · Tasks · Dependency order · Parallel groups · Checkpoints · Risk
+   assessment · Amendments · `EXPECTED_CODE_TARGETS:`), one line of intent under each. The K2 gate
+   reads this file — a plan that lives only in the conversation cannot pass it.
+2. **Then fill it one section per edit.** No single edit longer than ~120 lines. Every edit leaves the
+   file readable; none of them is allowed to wait for the section after it.
+3. **Never go more than 2 minutes without a tool call.** A thought that is getting long is the signal to
+   stop and write what you have — an edit is a checkpoint, not an interruption.
+4. **When you are unsure whether to read more or to write, WRITE.** A thin section refined later survives;
+   a perfect section you never reached does not.
+
+The skeleton is not a draft to apologise for. It is the artifact, opened early.
+
 ## Output
 
-### S-tier (inline)
-Inline checklist in conversation:
+### S-tier (minimal file — NOT inline-only)
+Write `features/<slug>/06_implementation_plan.md` with the checklist plus the machine-read block, and
+show the same checklist inline at the checkpoint:
 ```
 Implementation plan:
 - [ ] {task 1}
 - [ ] {task 2}
 - [ ] {task 3}
+
+EXPECTED_CODE_TARGETS:
+- {repo-relative path Step 7 will create or modify}
 ```
 
 ### M/L/XL
@@ -157,6 +190,48 @@ Create `features/<slug>/06_implementation_plan.md` with:
 
 Set `{IMPL_PLAN}` variable.
 
+## K2 plan-completeness gate (MANDATORY — Step 7 does not start until it exits 0)
+
+After the plan is written, run the gate. It is a script, not a judgement call:
+
+```bash
+node .claude/skills/feature-adr/scripts/check-plan-completeness.mjs features/<slug>
+```
+
+The path above is relative to the workspace the skill is INSTALLED in. Working inside a target repo
+that has no feature-adr install of its own? Pass the absolute path to the script instead — the
+ultracode workflow does this for you (it tries `args.gateScript`, then the workspace copy, then the
+target-repo copy, and refuses with `tooling-missing` if none exists). The gate is language-neutral:
+C2 recognises JS/TS, pytest, Go, Rust, JVM and .NET test paths, extensible per project with
+`testPathRules` in `architecture/project-skills.json`.
+
+| Exit | Verdict | What you do |
+|------|---------|-------------|
+| `0` | PASS | proceed to Step 7 |
+| `1` | FAIL | **return to Step 6** — fix the plan for every `FAIL C*` line, rerun the gate |
+| `3` | NOT-ESTABLISHED | **INCONCLUSIVE** — the gate could not read its inputs (no plan, plan under the size floor, ADR claims it cannot see). Fix the inputs and rerun. Never proceed. |
+
+Never proceed on a non-zero exit, and never treat empty output as a pass — the last line
+(`K2 plan-completeness: PASS|FAIL|NOT-ESTABLISHED`) is the verdict, and its absence is not one.
+What it checks: C1 every ADR has a plan task citing it · C2 every ADR Confirmation test path is named
+in the plan · C3 the `EXPECTED_CODE_TARGETS:` block parses line by line · C4 the feature's declared
+acid corpus is named · C5 (WARN) the `Inputs read:` line. An S-tier run with no `03_adr/` skips C1/C2
+with a note (it cannot be failed for ADRs it never had) — unless the plan itself cites `ADR-<n>`,
+which is NOT-ESTABLISHED. C1 is a grep: it catches "forgot entirely", not "mentioned but not tasked".
+
+Pass the run's tier so the check cannot be dodged: `--tier=S|M|L|XL`. An M/L/XL feature with no
+`03_adr/` FAILS C1/C2 (an M+ feature owes ADRs); only `--tier=S` — or no tier at all, and then the
+skip note says so — takes the skip. A declared-but-malformed acid table (lowercase `| a1 |`, a header
+with no parsable rows) FAILS as `C4-malformed`; it is not a skip.
+
+**If the gate fails in the ultracode workflow:** the run returns `phase: 'plan-gate-failed'` and the
+plan stage is CHECKPOINTED, so a bare re-invoke resumes the same failing plan. Repair it from outside:
+edit `features/<slug>/06_implementation_plan.md` to fix each `FAIL` line and re-invoke (the checkpoint
+is keyed on run INPUTS, not on the file, so your edit survives), or re-invoke with `args.resume:
+'never'` (or delete `features/<slug>/.fa-state/`) to force a fresh plan.
+
+The checkpoint banner's Gates line carries the verdict: `K2 plan-completeness ✓ | ✗ | inconclusive`.
+
 ## Checkpoint Format
 
 ```
@@ -167,6 +242,7 @@ Tier: {COMPLEXITY_TIER}
 
 {N} tasks in {M} parallel groups
 Estimated {K} files to create/modify
+🚦 Gates: K2 plan-completeness ✓ (exit 0)   ← ✗/inconclusive ⇒ do NOT start Step 7
 
 • "ок" — start coding
 • "разбей [TASK-N]" — split task further
@@ -196,3 +272,4 @@ re-flagging it. In the ultracode workflow this врезка runs automatically a
 - [ ] Parallel groups correctly identified
 - [ ] Each task touches identifiable files
 - [ ] Total file count matches complexity tier expectation
+- [ ] `check-plan-completeness.mjs features/<slug>` exited 0 (its output quoted at the checkpoint)

package/templates/.claude/skills/feature-adr/modules/08-qe.md

@@ -152,7 +152,7 @@ Fail the ADR gate for any miss:
 | Follow-up discipline | Consequences link follow-up ADRs or state none; after-action review is scheduled |
 | Confirmation stanza | Names verification method, monitoring, success metric, and owner |
 | Confirmation-to-test link | The named load-bearing property has a real automated test/fitness check by file/name |
-| No placeholders | No TODO, template hint text, raw prompt/generation scaffold, or empty tail sections |
+| No placeholders | No `TODO`, template hint text, raw prompt/generation scaffold, or empty tail sections |
 
 Reject explainer-masquerading-as-ADR: if the document describes a problem space or technology landscape but has no concrete `Decision`, record a BLOCKER.
 
@@ -182,6 +182,19 @@ paths — especially startup/lifespan/health: require a negative resource-down t
 path degrades per its declared contract: fail-open for advisory, explicit fail-fast for load-bearing).
 Missing → HIGH gap.
 
+### 3d. No-stubs gate (backlog 0b403a0106103901 — layer 1 of the cost-of-detection ladder)
+
+Over the files THIS RUN touched (the Step-7 change list; for a Codex coder, the landed-barrier file
+list), grep for unfinished-stub markers: `TODO` / `FIXME` / `HACK` / `XXX` / `PLACEHOLDER`
+(case-SENSITIVE, word-bounded — never add `-i`; `hackathon`/`todos` must not fire) plus the phrase
+`implement later` (case-insensitive). **Any match = the task shipped incomplete** → HIGH gap naming
+file:line, UNLESS the line carries an inline `no-stubs: <reason>` waiver WITH a non-empty reason, or
+`.dz/guard.json` `stubWaivers` lists the path WITH a reason. A REASONLESS waiver is itself a HIGH gap,
+never an exemption. Cross-check mechanically: `dz guard check --op publish --json` runs the same scan
+as the SOFT `no-stubs` rule over the working-tree diff. When you QUOTE a marker in `08_qe_report.md`,
+backtick it so the report itself scans clean (the claim-check forbidden-phrase convention). Record the
+verdict in the ADR Fitness section.
+
 ### 4. Multi-Agent Review Panel (L/XL)
 
 For L/XL features, spawn 3 parallel review agents using brutal-honesty modes: