@dzhechkov/skills-feature-adr 1.3.49 → 1.3.51

package/README.md

@@ -377,6 +377,39 @@ gate — not discovered in production.
 
 *\* Extended skills (marked with \*) are only available with `--full-qe-extended`*
 
+### Step 0 is architecture- & project-aware (opt-in, zero-config when absent)
+
+Beyond classifying the tier, **Step 0 now aligns the feature to your product and folds in project-specific
+skills** — both are fully opt-in and a run with neither file present is byte-identical to before.
+
+**Architecture сverka** (needs `dz` ≥ 0.3.111 + an `architecture/` map in the repo). Step 0 runs
+`dz architecture --check` against your product map + vision and surfaces the verdict in the checkpoint:
+```bash
+# author these two committed files once:
+#   architecture/subsystems.manifest.json   — the product's subsystems (the 5 jobs + foundation/arsenal/ops)
+#   architecture/vision.md                    — what the product is, where it goes, what it must NOT do
+dz architecture              # see the map
+dz architecture --check --slug <slug> --desc "<what you're building>" --cmd <new,cmds>
+```
+```
+⛔ block (confidence 0.90) — duplicate-command: "recall" already exists in subsystem "learn". Confirm this is intentional.
+```
+A `block` (a hard-stop, e.g. re-adding an existing command) is surfaced for your confirmation — it never
+auto-aborts. At the end of a complete run the map is refreshed (`architecture/map.json`) so the next feature's
+сverka sees this one.
+
+**Project-skill polymorphism** (needs `dz` ≥ 0.3.112). If the repo ships `architecture/project-skills.json`,
+Step 0 resolves it and folds each declared skill into its stage as **guidance** — so a generic pipeline
+becomes project-aware without editing the workflow:
+```json
+{ "version": 1,
+  "roles": { "product-vision": "architecture/vision.md", "critic": ".dz-skills/my-critic/SKILL.md" },
+  "extra": [ { "skill": ".dz-skills/security-checklist/SKILL.md", "phase": "qe", "as": "guidance" } ] }
+```
+Fixed roles map to fixed stages (`product-vision`→design+QE, `critic`→QE, `brand`→code, `impl-bar`→code); the
+open `extra` list adds guidance to any stage. `dz project-skills` prints the who-injected report. Absent ⇒ a
+normal generic run. (See `dz mr-rakes --gen-critic` to auto-generate the `critic` skill from your recurring rakes.)
+
 ### ADR quality gate (Step 3 generates → Step 8 enforces)
 
 Step 3 and Step 8 share an ADR best-practices contract distilled from the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dzhechkov/skills-feature-adr",
-  "version": "1.3.49",
+  "version": "1.3.51",
   "description": "Adaptive Feature Development skill pack for Claude Code — 11-step pipeline with Complexity Router (S/M/L/XL), ADR-driven architecture, 15 agentic-qe skills, multi-agent fleet QE. Supports --full-qe, --full-qe-extended, --with-learning, and --knowledge-extractor modes.",
   "bin": {
     "skills-feature-adr": "./bin/cli.js"

package/templates/.claude/skills/configure-feature-adr/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: configure-feature-adr
+description: |
+  Guided, conversational setup that makes feature-adr aware of THIS product — vision, architecture map,
+  testing/verification rules, and (optionally) a review critic — WITHOUT the user knowing any manifest schema.
+  Complex inside, simple outside.
+
+  TRIGGERS: "настрой feature-adr под мой продукт", "помоги настроить feature-adr", "configure feature-adr
+  for my product", "какие документы нужны для feature-adr и куда их добавить", "onboard feature-adr".
+
+  Uses the deterministic engine `dz feature-adr-setup` (plan → scaffold-from-spec, propose-confirm,
+  augment-never-clobber). Reuses `dz architecture` (map) and `dz mr-rakes --gen-critic` (auto critic).
+allowed-tools: Bash, Read, Write, Edit, AskUserQuestion
+---
+
+# Configure feature-adr for this product
+
+Turn a generic feature-adr into a **project-aware** one by scaffolding four committed files under
+`architecture/` and wiring `project-skills.json` — through a short conversation, not a schema lesson.
+
+**Golden rule:** you NEVER hand-write manifest JSON in front of the user, and you NEVER overwrite an existing
+file. The engine scaffolds; you interview only for what can't be auto-derived.
+
+## Protocol
+
+### 1. Read the current state (never writes)
+```bash
+dz feature-adr-setup --plan --json
+```
+Report in plain language: which of `vision.md` / `subsystems.manifest.json` / `testing.md` /
+`project-skills.json` already exist, how many workspace packages were discovered (a map can be
+auto-scaffolded), and whether a review corpus exists (a critic can be auto-generated). Tell the user exactly
+which documents are still missing — this is the "which docs, and where?" answer.
+
+### 2. Auto-derive what you can (confirm, don't dictate)
+- **Map:** take the discovered packages and propose a starter subsystem grouping (foundation / arsenal / your
+  app subsystems). Show it; ask the user to rename/split to their real subsystems. (Their product, their call.)
+- **Critic (optional):** if a review corpus exists, offer to run `dz mr-rakes --gen-critic
+  architecture/project-critic/SKILL.md --apply` to generate the critic role from their recurring rakes.
+
+### 3. Short interview — only the un-derivable
+Ask, ONE topic at a time (this is the whole point of the skill — keep it to a handful of questions):
+- **Product vision** — what the product IS (one paragraph), where it's going, and 1-3 things it consciously
+  does NOT do. Seed your draft from the repo README's "why/what" section, then confirm.
+- **Testing / verification** — the commands that prove "done" here (e.g. `pnpm test -- --run`), what "done"
+  means in this project, and any required gates (coverage, lint, typecheck). This becomes the `testing` role.
+- **Optional roles** — ask briefly whether they have a code implementation bar (`impl-bar`) or brand/UI rules
+  (`brand`) to point at; skip if not.
+
+### 4. Fill the SPEC and scaffold (propose-confirm)
+Write the collected answers to a spec file, then preview:
+```bash
+# spec shape: { vision:{core,direction?,boundaries?[],principles?[]}, testing:{commands?[],doneDefinition?,gates?[]},
+#               subsystems:[…], roles:{critic?:"auto"|path, brand?:path, "impl-bar"?:path}, extra?:[…] }
+dz feature-adr-setup --from-spec /tmp/feature-adr-spec.json          # preview: create / augment / unchanged per file
+```
+Show the preview. An **existing file is `unchanged` (never clobbered)**; a structured file is **augmented**
+(existing content kept, new added). On the user's explicit "yes":
+```bash
+dz feature-adr-setup --from-spec /tmp/feature-adr-spec.json --apply
+```
+
+### 5. Verify + hand off
+```bash
+dz project-skills          # confirm the roles resolve (product-vision, testing, critic, …)
+dz architecture --revise   # confirm no drift
+```
+Tell the user: from now on every `/feature-adr` in this repo folds their vision into design + QE, their
+testing rules into Step 8, and their critic into review — automatically. Re-run this skill any time the
+product grows; it only augments (new packages, fresh rakes), never overwrites.
+
+## Notes
+- **Re-run = update.** The same flow, idempotent: step 1 surfaces only what's new.
+- **Nothing is written without the user's confirmation**, and no hand-edited file is ever overwritten.
+- If `dz` is not set up, install it first (`npm i -g @dzhechkov/harness-cli`); the engine needs `dz` ≥ 0.3.116.

package/templates/.claude/workflows/feature-adr.js

@@ -548,6 +548,10 @@ async function designStage(promptText, opts, artifactPath, baseLabel) {
 
 const ROUTER = { type: 'object', additionalProperties: false, required: ['tier', 'activeSteps', 'rationale'], properties: { tier: { type: 'string', enum: ['S', 'M', 'L', 'XL'] }, activeSteps: { type: 'array', items: { type: 'number' } }, rationale: { type: 'string' } } }
 const ARTIFACT = { type: 'object', additionalProperties: false, required: ['wrote', 'summary'], properties: { wrote: { type: 'array', items: { type: 'string' } }, summary: { type: 'string' } } }
+// R2 polymorphic-feature-adr: the Step-0 project-skills probe returns only the small, reliable bits
+// (hasManifest + the who-injected report). The BIG per-stage guidance content is fetched by each stage
+// agent directly from `dz project-skills` (never threaded through a model → fidelity preserved).
+const PROJECT_SKILLS = { type: 'object', additionalProperties: false, required: ['hasManifest', 'report'], properties: { hasManifest: { type: 'boolean' }, report: { type: 'string' } } }
 const QE = { type: 'object', additionalProperties: false, required: ['grade', 'gaps', 'codeTestsAdequate', 'docTestsPresent'], properties: { grade: { type: 'string' }, codeTestsAdequate: { type: 'boolean' }, docTestsPresent: { type: 'boolean' }, gaps: { type: 'array', items: { type: 'object', additionalProperties: false, required: ['sev', 'what'], properties: { sev: { type: 'string' }, what: { type: 'string' } } } }, claimCheck: { type: 'object', additionalProperties: false, properties: { findings: { type: 'number' }, high: { type: 'number' }, medium: { type: 'number' } } } } }
 const ADR_TEMPLATE_GUIDE = 'ADR best-practices for Step 3: emit exactly one decision per ADR with the invariant core Title, Status, Context, Decision, Consequences. Template weight is tier-routed: S/M use Nygard/ITD-lightweight form but still include decision drivers, considered options, rationale, consequences, and Confirmation; L/XL use MADR structure plus an NHS Wales Confirmation stanza. Confirmation MUST name verification method, monitoring, success metric, and owner, and its load-bearing safety property MUST be tied to a Step-8 automated test/fitness function. Use status vocabulary proposed/accepted/rejected/deprecated/superseded plus a reversibility clause. Context must be neutral and appear before Decision. Considered Options must include rejected options with symmetric pros/cons. Rationale points must map to stated drivers and explain why losers were rejected. Consequences must include positive and negative outcomes/accepted downsides, follow-up ADR links, an after-action review schedule, and supersession discipline: supersession mints a new ADR and never edits accepted/rejected ADR content in place. Decision must be concrete/testable with exact names, versions, formats, paths, commands, or APIs. Reject explainer-masquerading-as-ADR: a domain overview with no concrete Decision is not an ADR. File names under 03_adr MUST be sequential NNN-{decision-slug}.md with lowercase kebab-case, dateless, ticketless slugs (the auto-001 ADR tracks the feature slug, so the present-tense imperative signal lives in the ADR Title; model-named additional ADRs use imperative slugs). Add a ## Links traceability block (requirements, driving use case, related ADRs) and a one-line provenance note (model-generated, edited for clarity); for a long ADR include a top-of-file table of contents.'
 const ADR_FITNESS_CHECKLIST = 'ADR fitness checklist for Step 8: read every ' + FDIR + '/03_adr/NNN-*.md ADR and fail the QE gate for any miss. Required checks: (1) filename is 03_adr/NNN-{decision-slug}.md where the slug is lowercase kebab-case, imperative, dateless, and ticketless; (2) title is decision-shaped and the ADR records one decision only; (3) Status is non-empty controlled vocabulary proposed/accepted/rejected/deprecated/superseded and includes a reversibility/revisit clause; (4) Context is neutral, problem-first, and appears before Decision; (5) Decision Drivers are stated and ranked/weighted; (6) Considered Options include the chosen and rejected options, each with symmetric pros and cons; (7) Rationale maps each point back to a driver and explains why rejected options lost; (8) Decision is concrete/testable with exact names, versions, formats, paths, commands, or APIs; (9) Consequences include positive and negative outcomes/accepted downsides, follow-up ADR links, and an after-action review schedule; (10) Confirmation names verification method, monitoring, success metric, and owner, then links the load-bearing safety property to an automated test/fitness function; (11) no placeholder text, template hints, raw generation scaffolding, or fake Markdown structure; (12) reject explainer-masquerading-as-ADR: describing a space with no concrete Decision is a blocker; (13) a Related/Links traceability block maps the ADR to its requirements, driving use case, and related ADRs. The ADR Confirmation check is load-bearing: assert the named safety property has a real test by file/name; if absent, grade no better than C and record a blocker gap.'
@@ -571,6 +575,28 @@ log('Router: tier ' + tier)
 // most visible moment. Uses the workspace bin (PATH-independent). Best-effort — never blocks.
 await agent('Run EXACTLY this one shell command via your Bash tool and report its stdout verbatim — do nothing else, do not summarize: ' + DZ + ' statusline --fa-record --slug ' + SLUG + ' --step "Step 0 recall" --recalled 3 --stored 0 --mode ' + MODE + ' --project ' + REPO, { label: 'fa-record:step0', phase: 'Router', effort: 'low' })
 
+// R1 product-architecture-lens (ADR-001 Decision 3): forward-looking сверка of THIS feature vs the LIVE
+// product map + vision. NON-BLOCKING/soft by design — it LOGS {signal,confidence} so a real command
+// duplication or vision-boundary tension is visible at Step 0; the hard-stop call stays the user's (a
+// false gate kills trust — the claim-check lesson). Best-effort; never blocks the run.
+await agent('Run EXACTLY this one shell command via your Bash tool and report its stdout verbatim — do nothing else, do not summarize: cd ' + REPO + ' && ' + DZ + ' architecture --check --slug ' + SLUG + " --desc '" + DESC.replace(/'/g, "'\\''") + "'", { label: 'arch-сverka:step0', phase: 'Router', effort: 'low' })
+
+// R2 polymorphic-feature-adr (ADR-001): probe the project skill manifest ONCE at Step 0. Returns only
+// {hasManifest, report} (small, reliable). NO manifest ⇒ PS_GUIDANCE returns '' for every stage, so the
+// stage prompts are byte-identical to today (FR-7 load-bearing). Fail-open: a probe error ⇒ generic run.
+let POLY = { hasManifest: false, report: '' }
+try {
+  const psProbe = await agent('Run EXACTLY this one shell command via your Bash tool: cd ' + REPO + ' && ' + DZ + ' project-skills --stages-json. It prints one JSON line {hasManifest, design, code, qe, report}. Return ONLY {hasManifest, report} from it (drop the big design/code/qe strings).', { label: 'project-skills:step0', phase: 'Router', effort: 'low', schema: PROJECT_SKILLS })
+  if (psProbe && typeof psProbe === 'object') POLY = psProbe
+} catch (e) { /* fail-open — generic run */ }
+if (POLY.hasManifest) log('Project skills: manifest active — folding project guidance into design/code/qe')
+// Constant fetch-instruction suffix, added to a stage's prompt ONLY when a manifest exists. The stage
+// agent fetches its OWN stage's guidance from `dz project-skills` (exact file content, no model
+// transcription). Empty string when no manifest ⇒ `prompt + PS_GUIDANCE(...)` is a no-op (byte-identical).
+const PS_GUIDANCE = (stage) => POLY.hasManifest
+  ? '\n\nPROJECT-SPECIFIC GUIDANCE (polymorphic feature-adr): this project ships a skill manifest. Via your Bash tool run EXACTLY `cd ' + REPO + ' && ' + DZ + ' project-skills --stages-json`, parse the JSON, and treat its `' + stage + '` field as AUTHORITATIVE project guidance for THIS step (product vision, conventions, checklists) — honor it as a hard constraint. If the command errors or hasManifest is false, ignore this paragraph.'
+  : ''
+
 // Steps 1-5: Design (tier-gated thunks built explicitly - no inline ternary-null)
 phase('Design')
 await usageProbe('Design')
@@ -592,7 +618,7 @@ modelsUsed.adr = modelLabel(adrOpts)
 modelsUsed.ideation = modelLabel(qcsdOpts)
 modelsUsed.architecture = modelLabel(archOpts)
 modelsUsed.ddd = modelLabel(archOpts)
-designThunks.push(() => designStage('Step 1 (Requirements)' + (isLplus ? ' + Step 2 (Research)' : '') + ' of /feature-adr for "' + DESC + '" (tier ' + tier + ', slug ' + SLUG + '). Code: ' + CODE_HINT + '. APPLY these Step-0 recalled LEARNED PATTERNS (fold the applicable ones into requirements/constraints - the loop paying off): ' + LEARNED + '. Write ' + FDIR + '/01_requirements.md (functional + non-functional requirements, acceptance criteria, constraints, and an "Applied learned patterns" note).' + reqExtra + ' Return wrote[] + a 1-line summary.', reqOpts, FDIR + '/01_requirements.md', 'requirements'))
+designThunks.push(() => designStage('Step 1 (Requirements)' + (isLplus ? ' + Step 2 (Research)' : '') + ' of /feature-adr for "' + DESC + '" (tier ' + tier + ', slug ' + SLUG + '). Code: ' + CODE_HINT + '. APPLY these Step-0 recalled LEARNED PATTERNS (fold the applicable ones into requirements/constraints - the loop paying off): ' + LEARNED + '. Write ' + FDIR + '/01_requirements.md (functional + non-functional requirements, acceptance criteria, constraints, and an "Applied learned patterns" note).' + reqExtra + ' Return wrote[] + a 1-line summary.' + PS_GUIDANCE('design'), reqOpts, FDIR + '/01_requirements.md', 'requirements'))
 if (isMplus) {
   designThunks.push(() => designStage('Step 3 (ADR + shift-left testability) of /feature-adr for "' + DESC + '" (' + SLUG + '). READ the actual code (' + CODE_HINT + ') to ground it. ' + ADR_TEMPLATE_GUIDE + ' Write ' + FDIR + '/03_adr/001-' + SLUG + '.md as a MADR-structured ADR that PASSES the Step-8 ADR fitness checklist (do NOT emit the legacy shape). Emit ALL of these sections, in order: a decision-shaped # Title (present-tense imperative verb — the auto-filename tracks the feature slug, so the IMPERATIVE signal lives in the title); ## Status (proposed/accepted/rejected/deprecated/superseded + a reversibility/revisit clause); ## Context (neutral, problem-first, BEFORE the Decision); ## Decision Drivers (ranked/weighted D1, D2, …); ## Considered Options (frame the CHOSEN approach as one option ALONGSIDE the rejected ones, each with symmetric Pros:/Cons:); ## Decision (concrete/testable — exact names, versions, paths, commands); ## Rationale (map each point to a driver Dn + why the losers lost); ## Consequences (Positive + Negative/Accepted Downsides + Follow-up ADRs + After-action Review with owner + date); a REQUIRED ## Confirmation stanza with Method:, Monitoring:, Success metric:, Owner:, Load-bearing property:, and Required automated check: `<test file>` NAMING the load-bearing property that MUST have a Step-8 test (the recurring lesson: the key safety property is often the untested one); and a ## Links traceability block (requirements, driving use case, related ADRs). Add a one-line provenance note (model-generated, edited for clarity) and, for a long ADR, a top-of-file table of contents. Do NOT use an "Alternatives considered" or "Testability/shift-left" heading in place of Considered Options / Confirmation. When creating ADDITIONAL ADRs, name them 03_adr/NNN-{decision-slug}.md with a lowercase-kebab, present-tense imperative, dateless, ticketless slug. Return wrote[] + summary.', adrOpts, FDIR + '/03_adr/001-' + SLUG + '.md', 'adr'))
   designThunks.push(() => designStage('Step 3.5 (QCSD ideation swarm - HTSM quality criteria + SFDIPOT risk) of /feature-adr for "' + DESC + '" (' + SLUG + '). Assess quality criteria + product-factors risk. Write ' + FDIR + '/03.5_ideation_report.md with a GO/CONDITIONAL/NO-GO verdict + top quality risks for QE. Return wrote[] + summary.', qcsdOpts, FDIR + '/03.5_ideation_report.md', 'qcsd'))
@@ -647,13 +673,13 @@ if (stopHere) {
   const qePlanned = qeShouldUseCodex() ? modelLabel(resolveStageModel('qe')) : modelLabel(mergeOpts({ agentType: 'qe-code-reviewer' }, resolveStageModel('qe')))
   const plannedModels = mergeOpts(modelsUsed, { code: codePlanned + ' (planned)', qe: qePlanned + ' (planned)' })
   if (isLplus) plannedModels.fleet = modelLabel(resolveStageModel('fleet')) + ' (planned)'
-  return { tier: tier, phase: 'checkpoint-after-plan', artifactsDir: FDIR, planner: (plan ? plan.planner : null), plan: (plan ? plan.summary : null), modelsUsed: plannedModels, usageEvents: usageEvents, usageThreshold: USAGE_THRESHOLD, note: 'L/XL checkpoint - review the ADR + plan (+ the planned code/qe/fleet models), then re-invoke with args.stopAfter="none" to implement + QE.' }
+  return { tier: tier, phase: 'checkpoint-after-plan', artifactsDir: FDIR, planner: (plan ? plan.planner : null), plan: (plan ? plan.summary : null), modelsUsed: plannedModels, usageEvents: usageEvents, usageThreshold: USAGE_THRESHOLD, polymorphism: POLY.hasManifest ? POLY.report : null, note: 'L/XL checkpoint - review the ADR + plan (+ the planned code/qe/fleet models), then re-invoke with args.stopAfter="none" to implement + QE.' }
 }
 
 // Step 7: Code (optional Codex fallback on Claude-limit exhaustion)
 phase('Code')
 await usageProbe('Code')
-const codePrompt = 'Step 7 (Code) of /feature-adr for "' + DESC + '" (' + SLUG + '). Implement the feature per the plan + ADR + architecture in ' + FDIR + '. Write the ACTUAL production code + its tests (mirror the closest existing implementation named in research/architecture). Follow repo conventions; build must pass. Write a change manifest ' + FDIR + '/07_code_changes/change_manifest.md listing every file touched. Return wrote[] (incl. real source files) + summary.' + ABSOLUTE_PATH_NOTE
+const codePrompt = 'Step 7 (Code) of /feature-adr for "' + DESC + '" (' + SLUG + '). Implement the feature per the plan + ADR + architecture in ' + FDIR + '. Write the ACTUAL production code + its tests (mirror the closest existing implementation named in research/architecture). Follow repo conventions; build must pass. Write a change manifest ' + FDIR + '/07_code_changes/change_manifest.md listing every file touched. Return wrote[] (incl. real source files) + summary.' + ABSOLUTE_PATH_NOTE + PS_GUIDANCE('code')
 // Resolve the coder model. args.models.code wins (a direct 'codex' spec = codex-first); else the legacy
 // CODER knob drives it (with its codex-fallback null-guard). resolveStageModel('code') folds both via the
 // code:null sentinel → resolveCoderSpec(). A Claude resolution merges {model} onto the Claude branch;
@@ -695,7 +721,7 @@ if (needsCodeLandedBarrier(coderUsed)) {
 // Step 8: QE (brutal-honesty, agentic-qe) + MANDATORY teach
 phase('QE')
 await usageProbe('QE')
-const qePrompt = 'Step 8 (QE - brutal-honesty review, agentic-qe) of /feature-adr for "' + DESC + '" (' + SLUG + '). Adversarially review the SHIPPED code (read it): correctness, edge cases, error handling, and the LOAD-BEARING property the ADR named (ASSERT it has a test - the recurring lesson). Run this ADR gate before final grading: ' + ADR_FITNESS_CHECKLIST + ' Grade A/B/C/D honestly. Assess code-test adequacy + doc-test presence. List CONFIRMED gaps with severity. Write ' + FDIR + '/08_qe_report.md with an ADR Fitness Checklist section showing PASS/FAIL per ADR and evidence for the Confirmation-linked test. MANDATORY SELF-LEARNING STORE (close the loop, never skip): compare every candidate lesson against the Step-0 recalled LEARNED patterns above. Teach ONLY lessons NOT covered by Step-0 recall. On overlap, run `dz teach --reinforce "<recalled pattern id or exact text>" --project ' + BRAIN + '` instead of minting a near-duplicate; if --reinforce is unavailable, skip the duplicate teach and report `reinforced existing pattern <id>` in the QE report. Store every genuinely new lesson in the CANONICAL BRAIN store at `' + BRAIN + '` so it is NOT lost to a target repo you may have cd`d into. Via Bash run EXACTLY `' + DZ_TEACH('<a durable reusable lesson from this feature - a rule/pattern/pitfall, NOT a checkpoint echo>', '<0.7-0.95>', '<area>') + '` for each genuine NEW lesson (1-3 max, high-signal) — the `cd ' + BRAIN + ' &&` prefix + `--project ' + BRAIN + '` pin guarantee the lesson lands in the brain regardless of your CWD. Then run `' + DZ + ' statusline --fa-record --slug ' + SLUG + ' --step "Step 8 QE" --recalled 3 --stored <count taught> --reinforced <count reinforced> --mode ' + MODE + ' --project ' + REPO + '` (run it verbatim via Bash, do not skip). Do NOT teach trivia or invent gaps. AUTHORING-TIME CLAIM-CHECK (Deliverable of claim-check-authoring-time): after writing ' + FDIR + '/08_qe_report.md, run EXACTLY `dz claim-check ' + FDIR + '/08_qe_report.md --json --fail-on none` via Bash, parse the {ok, findings, scanned} JSON, and report claimCheck: {findings: N, high: N, medium: N} (counts by severity) in your return object. TAG EVERY QUANTITATIVE CLAIM you write in the report using the convention the checker recognizes as honest — write "1131 tests pass (MEASURED — `npx vitest run`)", never a bare "1131 tests pass" — and where you QUOTE a forbidden phrase as an example (e.g. the retracted "100% passing" framing), backtick the literal so it reads as code, not an assertion, so your own compliant report scans clean. Return {grade, gaps, codeTestsAdequate, docTestsPresent, claimCheck}.' + ABSOLUTE_PATH_NOTE + landedNote
+const qePrompt = 'Step 8 (QE - brutal-honesty review, agentic-qe) of /feature-adr for "' + DESC + '" (' + SLUG + '). Adversarially review the SHIPPED code (read it): correctness, edge cases, error handling, and the LOAD-BEARING property the ADR named (ASSERT it has a test - the recurring lesson). Run this ADR gate before final grading: ' + ADR_FITNESS_CHECKLIST + ' Grade A/B/C/D honestly. Assess code-test adequacy + doc-test presence. List CONFIRMED gaps with severity. Write ' + FDIR + '/08_qe_report.md with an ADR Fitness Checklist section showing PASS/FAIL per ADR and evidence for the Confirmation-linked test. MANDATORY SELF-LEARNING STORE (close the loop, never skip): compare every candidate lesson against the Step-0 recalled LEARNED patterns above. Teach ONLY lessons NOT covered by Step-0 recall. On overlap, run `dz teach --reinforce "<recalled pattern id or exact text>" --project ' + BRAIN + '` instead of minting a near-duplicate; if --reinforce is unavailable, skip the duplicate teach and report `reinforced existing pattern <id>` in the QE report. Store every genuinely new lesson in the CANONICAL BRAIN store at `' + BRAIN + '` so it is NOT lost to a target repo you may have cd`d into. Via Bash run EXACTLY `' + DZ_TEACH('<a durable reusable lesson from this feature - a rule/pattern/pitfall, NOT a checkpoint echo>', '<0.7-0.95>', '<area>') + '` for each genuine NEW lesson (1-3 max, high-signal) — the `cd ' + BRAIN + ' &&` prefix + `--project ' + BRAIN + '` pin guarantee the lesson lands in the brain regardless of your CWD. Then run `' + DZ + ' statusline --fa-record --slug ' + SLUG + ' --step "Step 8 QE" --recalled 3 --stored <count taught> --reinforced <count reinforced> --mode ' + MODE + ' --project ' + REPO + '` (run it verbatim via Bash, do not skip). Do NOT teach trivia or invent gaps. AUTHORING-TIME CLAIM-CHECK (Deliverable of claim-check-authoring-time): after writing ' + FDIR + '/08_qe_report.md, run EXACTLY `dz claim-check ' + FDIR + '/08_qe_report.md --json --fail-on none` via Bash, parse the {ok, findings, scanned} JSON, and report claimCheck: {findings: N, high: N, medium: N} (counts by severity) in your return object. TAG EVERY QUANTITATIVE CLAIM you write in the report using the convention the checker recognizes as honest — write "1131 tests pass (MEASURED — `npx vitest run`)", never a bare "1131 tests pass" — and where you QUOTE a forbidden phrase as an example (e.g. the retracted "100% passing" framing), backtick the literal so it reads as code, not an assertion, so your own compliant report scans clean. Return {grade, gaps, codeTestsAdequate, docTestsPresent, claimCheck}.' + ABSOLUTE_PATH_NOTE + landedNote + PS_GUIDANCE('qe')
 // CROSS-MODEL QE (load-bearing): resolveStageModel('qe') derives the OTHER family than the resolved
 // coder when args.models.qe is unset (coder-codex ⇒ opus; coder-Claude ⇒ codex, or opus if codex absent).
 // An explicit args.models.qe wins. A Claude qe spec is merged onto the qe-code-reviewer base (role
@@ -765,6 +791,11 @@ if (isLplus) {
   fleet = 'run'
 }
 
+// R1 product-architecture-lens (FR-3): refresh architecture/map.json at the END of a COMPLETE run so the
+// NEXT feature's Step-0 сверка sees what this run added. Best-effort, non-blocking. (Not reached on the
+// L/XL checkpoint-after-plan return above — no code has landed there yet.)
+await agent('Run EXACTLY this one shell command via your Bash tool and report its stdout verbatim — do nothing else, do not summarize: cd ' + REPO + ' && ' + DZ + ' architecture --json > architecture/map.json && echo arch-map-updated', { label: 'arch-map:refresh', phase: (isLplus ? 'FleetQE' : 'QE'), effort: 'low' })
+
 const tags = ['FEATURE_ADR_ROUTED', 'FEATURE_ADR_DESIGNED', 'FEATURE_ADR_PLANNED', 'FEATURE_ADR_IMPLEMENTED', 'FEATURE_ADR_VERIFIED']
 if (isLplus) tags.push('FEATURE_ADR_FLEET_VERIFIED')
 return {
@@ -785,6 +816,7 @@ return {
   usageThreshold: USAGE_THRESHOLD,
   selfLearning: 'recall@Step0 + teach@Step8 (mandatory)',
   brain: BRAIN,
+  polymorphism: POLY.hasManifest ? POLY.report : null,
   claimGate: claimGate,
   promiseTags: tags,
 }