@techierathore/techieflow 1.0.0

package/.tfcore/tasks/advanced-elicitation.md

@@ -0,0 +1,117 @@
+# Advanced Elicitation Task
+
+## Purpose
+
+- Provide optional reflective and brainstorming actions to enhance content quality
+- Enable deeper exploration of ideas through structured elicitation techniques
+- Support iterative refinement through multiple analytical perspectives
+- Usable during template-driven document creation or any chat conversation
+
+## Usage Scenarios
+
+### Scenario 1: Template Document Creation
+
+After outputting a section during document creation:
+
+1. **Section Review**: Ask user to review the drafted section
+2. **Offer Elicitation**: Present 9 carefully selected elicitation methods
+3. **Simple Selection**: User types a number (0-8) to engage method, or 9 to proceed
+4. **Execute & Loop**: Apply selected method, then re-offer choices until user proceeds
+
+### Scenario 2: General Chat Elicitation
+
+User can request advanced elicitation on any agent output:
+
+- User says "do advanced elicitation" or similar
+- Agent selects 9 relevant methods for the context
+- Same simple 0-9 selection process
+
+## Task Instructions
+
+### 1. Intelligent Method Selection
+
+**Context Analysis**: Before presenting options, analyze:
+
+- **Content Type**: Technical specs, user stories, architecture, requirements, etc.
+- **Complexity Level**: Simple, moderate, or complex content
+- **Stakeholder Needs**: Who will use this information
+- **Risk Level**: High-impact decisions vs routine items
+- **Creative Potential**: Opportunities for innovation or alternatives
+
+**Method Selection Strategy**:
+
+1. **Always Include Core Methods** (choose 3-4):
+   - Expand or Contract for Audience
+   - Critique and Refine
+   - Identify Potential Risks
+   - Assess Alignment with Goals
+
+2. **Context-Specific Methods** (choose 4-5):
+   - **Technical Content**: Tree of Thoughts, ReWOO, Meta-Prompting
+   - **User-Facing Content**: Agile Team Perspective, Stakeholder Roundtable
+   - **Creative Content**: Innovation Tournament, Escape Room Challenge
+   - **Strategic Content**: Red Team vs Blue Team, Hindsight Reflection
+
+3. **Always Include**: "Proceed / No Further Actions" as option 9
+
+### 2. Section Context and Review
+
+When invoked after outputting a section:
+
+1. **Provide Context Summary**: Give a brief 1-2 sentence summary of what the user should look for in the section just presented
+
+2. **Explain Visual Elements**: If the section contains diagrams, explain them briefly before offering elicitation options
+
+3. **Clarify Scope Options**: If the section contains multiple distinct items, inform the user they can apply elicitation actions to:
+   - The entire section as a whole
+   - Individual items within the section (specify which item when selecting an action)
+
+### 3. Present Elicitation Options
+
+**Review Request Process:**
+
+- Ask the user to review the drafted section
+- In the SAME message, inform them they can suggest direct changes OR select an elicitation method
+- Present 9 intelligently selected methods (0-8) plus "Proceed" (9)
+- Keep descriptions short - just the method name
+- Await simple numeric selection
+
+**Action List Presentation Format:**
+
+```text
+**Advanced Elicitation Options**
+Choose a number (0-8) or 9 to proceed:
+
+0. [Method Name]
+1. [Method Name]
+2. [Method Name]
+3. [Method Name]
+4. [Method Name]
+5. [Method Name]
+6. [Method Name]
+7. [Method Name]
+8. [Method Name]
+9. Proceed / No Further Actions
+```
+
+**Response Handling:**
+
+- **Numbers 0-8**: Execute the selected method, then re-offer the choice
+- **Number 9**: Proceed to next section or continue conversation
+- **Direct Feedback**: Apply user's suggested changes and continue
+
+### 4. Method Execution Framework
+
+**Execution Process:**
+
+1. **Retrieve Method**: Access the specific elicitation method from the elicitation-methods data file
+2. **Apply Context**: Execute the method from your current role's perspective
+3. **Provide Results**: Deliver insights, critiques, or alternatives relevant to the content
+4. **Re-offer Choice**: Present the same 9 options again until user selects 9 or gives direct feedback
+
+**Execution Guidelines:**
+
+- **Be Concise**: Focus on actionable insights, not lengthy explanations
+- **Stay Relevant**: Tie all elicitation back to the specific content being analyzed
+- **Identify Personas**: For multi-persona methods, clearly identify which viewpoint is speaking
+- **Maintain Flow**: Keep the process moving efficiently

package/.tfcore/tasks/amend-docs.md

@@ -0,0 +1,149 @@
+# amend-docs
+
+Update the existing day-1 docs **in place** when a project's concept or requirements evolve — mid-development, or during the back-and-forth of defining a greenfield project. Surgically amends the BRD + Architecture (and ripples PROJECT-STATUS / BRD §4 / the checklists), preserving everything that didn't change. This is the **incremental** counterpart to re-running `*day1-*` (which archives the old docs and regenerates wholesale).
+
+## When to use vs the alternatives
+
+- **`*amend-docs`** (this task) — the concept shifted, or requirements were added / reworded / dropped, and you want to keep the existing docs and IDs and just fold the change in. Surgical, append-only, no archive.
+- **`*author-brd`** — add NEW requirements interactively, one at a time (per-item elicitation). Use when you only need additions and want to confirm each. (`*amend-docs` can call into its append-only ID semantics for the additive part.)
+- **Re-run `*day1-greenfield` / `*day1-brownfield`** — a full concept pivot where most of the docs are now wrong. The §1.6 collision policy archives the old docs to `docs/OldDocs/` and writes fresh. Do NOT use `*amend-docs` for that.
+
+## Inputs
+
+- `{AppName}` (required; or resolve from `core-config.yaml`).
+- `{Change}` — free-form description of what changed: new features, reworded/expanded requirements, removed scope, stack changes, a new external integration, etc. May also be a **path to an amended concept doc / notes** to harvest. If absent, ask once: "What changed? Describe the new/changed/removed features or paste the amended concept (any length). I'll fold it into the BRD + Architecture without disturbing the rest."
+- `{Scope}` — OPTIONAL: `brd` | `architecture` | `both` (default `both`).
+
+## SEQUENTIAL Execution
+
+### 1. Load the targets
+
+- Read `.tfcore/core-config.yaml`; resolve `{AppName}`, the BRD (`docs/{AppName}-BRD.md`), and the Architecture (`docs/{AppName}-Architecture.md`). Note the highest existing `BRD-N`.
+- Check whether the checklist exists (`docs/{AppName}-Checklist.md`) — it does iff `*split-brd` has run. This decides §6 (ripple).
+- If a BRD doesn't exist at all, this isn't an amend — tell the user to run `*day1-*` first, and HALT.
+
+### 2. Parse the change into a change-set
+
+Classify every item in `{Change}` (harvesting a concept-doc path if given) into:
+
+- **ADD** — a new capability / requirement / actor / integration not in the BRD yet.
+- **MODIFY** — an existing capability whose behavior/scope changed (map it to the owning `BRD-N` / `F-code`).
+- **REMOVE** — scope being dropped (map to the owning `BRD-N`).
+- **ARCH** — structural impact: new/changed module, new runtime flow, stack/library change, new ADR-worthy decision.
+
+### 3. Confirm the change-set ONCE before writing (single gate, not per-item)
+
+Present the parsed change-set as a numbered table and ask the user to confirm or amend it:
+
+```
+Proposed amendments to {AppName}:
+ADD     → new BRD-{next..} : {one-line each}
+MODIFY  → BRD-{n} : {old → new, one line}
+REMOVE  → BRD-{n} : {reason}
+ARCH    → {module/flow/ADR} : {what changes}
+Confirm to apply (these are in-place edits; existing BRD IDs are never renumbered). Reply `go`, or correct any line.
+```
+
+Wait for `go` (or corrections, then re-show). This is the ONLY interaction — once confirmed, apply everything in bulk. (For a purely additive change where the user wants per-item confirmation instead, defer to `.tfcore/tasks/author-brd.md` for the ADD items and skip this gate.)
+
+### 4. Amend the BRD (append-only, in place)
+
+Apply the confirmed change-set to `docs/{AppName}-BRD.md` — **edit in place, do NOT archive to OldDocs, do NOT regenerate the whole doc, preserve every unchanged section verbatim:**
+
+- **ADD** → assign the next unused `BRD-N` (continue from the highest; never reuse a removed ID). Add/extend the owning `### F-{CODE}` feature-catalog entry (what/why, screens table, workflow, owning BRD-N), append the one-line statement to the §10 ledger, and add a `Planned` row to the §4 Development-status table for any new F-code.
+- **MODIFY** → edit the EXISTING `BRD-N` text in place (keep the ID) and update its feature-catalog entry. Note the revision inline if helpful.
+- **REMOVE** → mark `~~BRD-N~~ (removed {YYYY-MM-DD}: reason)` in the ledger and its feature entry — **never delete or renumber**. The ID stays retired.
+- **Diagrams:** update any BRD diagram the change touches; add a diagram for any new multi-step/multi-actor flow. Every diagram MUST follow `.tfcore/templates/v4custom/html-render-shell.md §5.5` (quoted labels, no `end` node id).
+- **Footer:** update `Highest BRD ID: BRD-{N}` and add/update a `Last amended: {YYYY-MM-DD} — {one-line summary}` line.
+- **INFORMATION-PRESERVATION:** the amended BRD is a superset of the prior one minus only the explicitly-removed items — never a re-summarization. If the doc got shorter for any reason other than a REMOVE, you over-compressed; restore it.
+
+### 5. Amend the Architecture (in place)
+
+If `{Scope}` includes architecture and there are ARCH items, edit `docs/{AppName}-Architecture.md` in place:
+
+- Update the affected §4 modules (prose + table rows), add new modules where introduced — preserve unchanged modules verbatim.
+- Update or add the runtime flow diagrams the change affects (§5.5 authoring rules).
+- Add an ADR for any new significant decision (`ADR-{next} — {decision}` with a one-line reason); never rewrite a historical ADR — supersede it with a new one if reversed.
+- Update the stack line if the change altered it.
+- Status note: keep the existing status (`Target` / `Current`) and append `amended {YYYY-MM-DD}: {summary}`.
+
+### 6. Ripple to the checklist (only if it already exists)
+
+If `*split-brd` has run (checklist present), the BRD change must reach the per-REQ table — but **never clobber existing statuses by re-splitting blindly:**
+
+- **New BRD-N (ADD):** append new `REQ-*` row(s) to the one checklist `docs/{AppName}-Checklist.md` (the prefix carries the type — `REQ-UI/FN/NFR/RAG-*`), Status `Not started`, with the new ID's acceptance criteria in its Details anchor. Pick the REQ type the way `split-brd` does. **If the ADD is a UI change and mockups exist** (`docs/{AppName}-UIDesign.md`), the new `REQ-UI-*` should cite its mockup screen — if that screen doesn't exist yet, flag it in the §7 report to run `*mockups {AppName} --update` so the new screen gets a mockup before build.
+- **MODIFY:** find the REQ rows derived from that BRD-N and set their Status to `Needs re-verify` (or add a Remark) so the verifier re-grades them — do not silently flip to Verified.
+- **REMOVE:** mark the derived REQ rows `N/A (removed {date})`; keep the rows for traceability.
+- If the mapping from BRD-N → REQ-* is non-obvious for a MODIFY/REMOVE, list those rows in the §7 report and ask the user rather than guessing.
+- **If the checklist does NOT exist yet** (pre-split greenfield still in discovery): nothing to ripple — note that the next `*split-brd {AppName}` will pick up all the amendments.
+
+### 7. Re-render + status gate (MANDATORY)
+
+- Re-render the touched HUMAN docs to HTML via `.tfcore/tasks/generate-html.md` (shared shell): `docs/{AppName}-BRD.html` always; `docs/{AppName}-Architecture.html` if §5 ran. **Do NOT render the checklist to HTML** even though §6 may have changed its rows — it is an AI-agent working document kept in markdown only. (If the amendment changed code-level flows, refresh the DevGuide separately via `*devguide {AppName}`; if it changed greenfield UI/screens, refresh the mockups via `*mockups {AppName} --update`.)
+- **Run `.tfcore/tasks/_status-update-gate.md`:** update `PROJECT-STATUS.md` (`last_updated`, a "Where I am" line noting the amendment, the BRD §4 Development-status rollup per gate item 9) and re-render `PROJECT-STATUS.html`. Add a one-line note to PROJECT-STATUS: `Docs amended {date}: {summary}`.
+
+### 7a. Emit the run record (telemetry)
+
+Same turn as the status/PROJECT-STATUS write. Doctrine + the ten constraints: `.tfcore/tasks/_metrics-emit-gate.md`. Schema: `.tfcore/telemetry/SCHEMA.md` §2. Stamp `started` with `date -u +%Y-%m-%dT%H:%M:%SZ` as your FIRST action of this task — it cannot be reconstructed at the end.
+
+```bash
+cat <<'JSON' | bash .tfcore/utils/tf-emit.sh runs
+{"kind":"run","app":"{AppName}","cmd":"amend-docs","mode":null,
+ "started":"<start>","ended":"<now>","duration_s":<n>,
+ "reqs_touched":[],"reqs_count":0,
+ "subagents":[],"files_written":<n>,"build_result":"not-run"}
+JSON
+```
+
+`reqs_touched` carries REQ IDs only — never requirement text — and `[]` is correct when this task touched no specific REQ.
+
+**If this amendment closes a gap the day-1 docs should have covered, record it as a miss** (SCHEMA.md §5.5). Not every amendment is a miss: a genuine change of mind, a new feature the owner decided on today, or an evolving concept is **scope arriving late, not a mistake**, and recording it as one would make the design-miss share meaningless. Emit only when the answer to *"should the original BRD/Architecture have said this?"* is plainly yes — a behaviour that was always required and was never written down, or two sections that contradicted each other.
+
+```bash
+MID=$(bash .tfcore/utils/tf-emit.sh --next-miss-id)
+cat <<JSON | bash .tfcore/utils/tf-emit.sh misses
+{"kind":"miss","miss_id":"$MID","req_id":null,
+ "miss_class":"unspecified-gap","artifact":"brd","severity":"minor",
+ "why_missed":"missing-checklist-item",
+ "origin_phase":"day1-greenfield","origin_agent":"analyst",
+ "origin_run_id":"<started of the day1/split-brd run, from runs.jsonl>",
+ "found_by":"owner","found_phase":"amend-docs",
+ "found_gate":null,"found_run_id":"<start>","failure_class":null}
+JSON
+```
+
+Use `spec-contradiction` where two requirements could not both hold, and `artifact:"architecture"` / `"uidesign"` where the gap was there rather than in the BRD. `found_by` is `"owner"` when the owner named the gap, `"agent-review"` when you found it while amending something else.
+
+**Telemetry has no veto:** if the emit fails, the phase still succeeded; do not retry, do not diagnose, do not mention it.
+
+### 8. HALT — amendment report
+
+Print:
+
+```
+# Docs amended — {AppName}
+BRD:   +{a} added (BRD-{x}..BRD-{y}) · {m} modified · {r} removed   (highest now BRD-{N})
+Arch:  {modules/flows/ADRs touched, or "no change"}
+Checklist: {rows appended / flagged for re-verify / removed, or "not split yet — run *split-brd"}
+Re-rendered: {list of .html}
+
+Next: {if new reqs and not split → "*split-brd {AppName}"} / {if new UI screens need mockups → "*mockups {AppName} --update"} / {if reqs need building → "*build-phase {AppName}"} / {else "review the rendered docs"}
+```
+
+## Hard rules
+
+- **In-place, surgical.** Preserve every unchanged section verbatim. NEVER archive the doc to `docs/OldDocs/` and NEVER regenerate the whole doc — that is `*day1-*`'s job, and using it here would destroy unchanged content and history.
+- **BRD IDs are append-only.** Never renumber; removed IDs are struck through and retired, never reused.
+- **One confirmation gate** (§3), then bulk-apply. Do not per-item elicit unless the user explicitly wants the additive-only `*author-brd` path.
+- **Never edit source code.** This task only touches the docs (and the checklist Status tables per §6).
+- **Full pivot ≠ amendment.** If the change invalidates most of the BRD/Architecture, tell the user to re-run `*day1-greenfield`/`*day1-brownfield` instead, and HALT.
+
+## Output Checklist
+
+- [ ] Change-set parsed (ADD/MODIFY/REMOVE/ARCH) and confirmed once with the user
+- [ ] BRD amended in place — new BRD-N appended, modified IDs edited in place, removed IDs struck through; §4/§9/§10 + footer updated; no renumbering; no OldDocs archive
+- [ ] Architecture amended in place (if in scope) — modules/flows/ADRs updated, unchanged sections preserved
+- [ ] Checklist rippled (new REQ rows appended / modified flagged for re-verify / removed marked) — or noted "not split yet"
+- [ ] BRD.html (+ Architecture.html as touched) re-rendered; every diagram passes the §5.5 self-check (the checklist is NOT rendered to HTML — markdown only)
+- [ ] PROJECT-STATUS.md updated via the status gate (incl. BRD §4 rollup) + PROJECT-STATUS.html re-rendered
+- [ ] Amendment report printed with the next command

package/.tfcore/tasks/author-brd.md

@@ -0,0 +1,79 @@
+# author-brd
+
+Author or extend a Business Requirements Document (BRD) with stable BRD-N requirement IDs, using interactive elicitation. The analyst NEVER assumes a requirement — each candidate is confirmed by the user before it lands in the BRD.
+
+> **When to use:** this is the INTERACTIVE alternative for extending an existing BRD requirement-by-requirement. For creating a project's BRD, the default path is `*day1-brownfield` / `*day1-greenfield` (bulk draft, no per-item confirmation).
+
+## Purpose
+
+Produce a BRD where every business/functional requirement has a unique, stable, append-only ID (`BRD-1`, `BRD-2`, …) that downstream agents (UI agent, orchestrator, verifier) can declare and verify against. Eliminate the "implicit requirement" problem by forcing per-item user confirmation.
+
+## elicit
+
+elicit=true — this task REQUIRES user interaction. Never skip elicitation for efficiency.
+
+## Inputs
+
+- `{AppName}` argument (required for the canonical filename; ask once if missing).
+- `{topic}` argument (optional) — the product/feature area. If absent, ask once: "What's the topic / product area for this BRD?"
+- Existing BRD path. Resolve in this order: `core-config.yaml → customTechnicalDocuments`, then `docs/{AppName}-BRD.md` (legacy fallbacks: `docs/brd.md`, `docs/BRD.md`). If found, OPEN it and continue from the highest existing BRD-N. If not found, create `docs/{AppName}-BRD.md` from `.tfcore/templates/v4custom/app-brd-tmpl.md` (feature catalog + §10 BRD-N ledger shape — NOT ad-hoc "Phase N" sections).
+
+## SEQUENTIAL Execution
+
+### 1. Read or scaffold the BRD
+
+- If the resolved BRD exists: read it, parse all existing `BRD-{N}` IDs, and record the highest N. New requirements continue from N+1.
+- If absent: scaffold `docs/{AppName}-BRD.md` from `.tfcore/templates/v4custom/app-brd-tmpl.md` (leave unconfirmed sections empty; confirmed requirements land in the §10 ledger).
+- Ask the user which areas they want to scope today.
+
+### 2. Drive elicitation per area, one at a time
+
+For each area the user wants to cover (UI, data, workflow, NFRs, etc.):
+
+1. Generate a numbered list of CANDIDATE requirements for that area — 3 to 7 items, written as one-line "user can X" / "system shall Y" statements. Do NOT assign BRD-N IDs yet.
+2. Present the list and ask the user to (a) accept, (b) reject, (c) refine, or (d) add their own — one item at a time. Use this exact prompt format:
+   ```
+   Candidate requirements for {area}:
+   1. {candidate}
+   2. {candidate}
+   ...
+   For each, reply: keep / drop / refine: <new text>. Or add a new one with: add: <text>.
+   ```
+3. After the user processes each item, assign the next BRD-N to every KEPT or REFINED item, in the order they were confirmed. Show the assignments back:
+   ```
+   Assigned:
+   - BRD-{N}: {final text}
+   - BRD-{N+1}: {final text}
+   ```
+4. Append the assigned requirements to the §10 Functional-requirements ledger of the resolved BRD file (and flesh out / create the owning feature-catalog entry).
+
+Repeat for each area until the user says they're done with this BRD pass.
+
+### 3. NFRs and acceptance criteria (optional pass)
+
+If the user wants NFRs (performance, accessibility, browser support, etc.) or acceptance criteria for any BRD-N, run the same elicitation pattern. NFRs get their own BRD-N IDs (do NOT use a separate `NFR-N` series — keep one ID space so the verifier can grade everything uniformly).
+
+### 4. Final output
+
+Append/refresh the footer block of the BRD:
+```
+---
+Last updated: {YYYY-MM-DD}
+Highest BRD ID: BRD-{N}
+```
+
+Print a compact summary to the user:
+```
+BRD updated → docs/{AppName}-BRD.md
+Added: BRD-{a}..BRD-{b} ({count} requirements)
+Phases touched: {list}
+```
+
+HALT.
+
+## Hard rules
+
+- elicit=true — never batch-confirm; one item at a time.
+- BRD-N IDs are append-only — never renumber an existing ID even if the user removes a requirement later (mark it `~~BRD-N~~ (removed)` instead).
+- Requirements are written as observable outcomes, not implementation hints. The verifier needs to be able to test them.
+- The analyst writes the BRD; the analyst does NOT implement anything.

package/.tfcore/tasks/build-phase.md

@@ -0,0 +1,231 @@
+# build-phase
+
+The single unified build. Implement every open REQ in `docs/{AppName}-Checklist.md` — UI, functional, RAG, and NFR — then self-smoke (data + visual) and chain the verifier automatically.
+
+## Purpose
+
+There is one build phase for the whole app. `build-phase` (driven by **flow-master**) reads the one checklist, clusters ALL open REQs, and fans the work out — **calling the library agents as sub-agents** rather than as separate phase commands:
+- `REQ-UI-*` clusters → built by invoking **`/trblazeui`** as a sub-agent, **from the approved mockups** (`docs/{AppName}-UIDesign.md` + `docs/mockups/*.html`).
+- `REQ-RAG-*` clusters → built by invoking **`/techierag`** as a sub-agent.
+- `REQ-FN-*` / `REQ-NFR-*` clusters → built directly by flow-master's own general-purpose subagents.
+
+There is no separate `build-ui-phase` / `build-rag-phase` command — those were dissolved; trblazeui and techierag are skills this phase calls.
+
+## Inputs
+
+- `{AppName}` argument (required; or resolve from core-config.yaml).
+
+## SEQUENTIAL Execution
+
+### 0. Stamp the start time
+
+Run `date -u +%Y-%m-%dT%H:%M:%SZ` and keep the value — it is this run's `started` for the §7a telemetry emit. It cannot be reconstructed at the end, and an invented duration is a fabricated measurement.
+
+### 1. Required reading
+1. `docs/{AppName}-Coding-Standards.md` — strict compliance (`obj` field prefix where the project uses one, `a`/`v` prefixes, no underscores, file-scoped namespace, XML docs)
+2. `docs/{AppName}-Architecture.md` — module boundaries
+3. `docs/{AppName}-Checklist.md` — the work list (all REQ classes)
+4. **The UI design source** — greenfield: `docs/{AppName}-UIDesign.md` + `docs/mockups/*.html` (build UI to match the approved mockups); brownfield: `docs/{AppName}-DevGuide.md` (or the split set under `docs/devguides/`) for the as-built screen map.
+5. The library references when their REQ classes are in scope: `.trblazeui/TrBlazeUI-AI-Reference.md` (if absent, run `dotnet build` once to deploy), `.techierag/TechieRag-AI-Reference.md`.
+
+### 2. Scope filtering — ALL open REQs
+
+Working list = every non-terminal REQ in the checklist, all prefixes (UI / FN / RAG / NFR). No prefix is excluded.
+
+### 2a. Re-entry mode detection (FIX vs FRESH)
+
+Read the **Requirements Status** table in `docs/{AppName}-Checklist.md` (the single source of truth — no separate dated coverage files). **Terminal statuses — never rebuild, never count as open:** `Verified`, `Done (pre-existing)` (migrated from a dev plan; do NOT re-implement), `N/A`.
+
+- Any row `FAIL` / `PARTIAL` / `In Progress` / `Needs re-verify` → **FIX mode**, working list = only those REQ IDs. (`Blocked` rows are library gaps — pass through unless the blocking TR entry is marked resolved.)
+- Every row terminal (or terminal + `Blocked`) → nothing to build; say so and update PROJECT-STATUS (§7).
+- Otherwise → **FRESH mode**, working list = all non-terminal, non-`Blocked` REQs.
+
+Echo one line: `Mode: FIX — N items: REQ-UI-3, REQ-FN-2` or `Mode: FRESH — N items`.
+
+### 2b. ONE PASS = THE WHOLE WORKING LIST (owner rule 2026-08-21 — non-negotiable)
+
+**A build pass is finished when every REQ on the working list from §2a has reached at least `Implemented` (or a genuine `Blocked`), the verifier has been chained (§6b), and its FAIL rows have been looped (§6c). Not before.** The owner's observed anti-pattern — implement some REQs, update PROJECT-STATUS with "run `*build-phase` again for the remaining REQs", end the turn — is **banned**. The point of the build phase is that *all* checklist items reach the verify stage in one go, so the owner can then call the verifier once over everything.
+
+- **Do not shrink the working list** to "the first cluster", "the UI ones", "what fits this turn". §3 already fans the list out across parallel sub-agents; a long list means **more clusters and more sub-agents**, never a shorter pass. If your own context is filling up, delegate the remaining clusters to fresh sub-agents (each gets its REQ IDs + acceptance + the two standing rules) and keep only the cluster table + returns in your context. **Context pressure is a reason to delegate, not to stop.**
+- **Wait for every cluster.** §3 says "wait for ALL sub-agents to return" — that includes clusters you spawned late to replace a failed or partial return. A cluster that comes back `PARTIAL` is re-spawned with the missing REQs before you move to §5.
+- **Legitimate reasons for an open REQ to remain below `Implemented` at the end of a pass — and there are only these:** `Blocked` by a logged library gap (TR-NNN entry exists, workaround impossible); a REQ whose acceptance cannot be met without an owner-only asset (credentials, a paid account, a physical device, a product decision) — record it in PROJECT-STATUS "Known blockers" with the exact ask. "Ran out of time/turns", "large scope", "will do in the next pass" are **not** reasons.
+- **The next command after a complete pass is the verifier's or the owner's, never "build again for the rest".** `*build-phase` may appear as the next command only for FIX mode (verifier `FAIL` / `Needs re-verify` rows, §6b/§7) or once a `Blocked` library gap is resolved.
+- Under YOLO / goal mode (`.tfcore/tasks/_yolo-mode.md`) this section is doubly binding: there is nobody to "run it again".
+
+### 3. Dependency analysis + parallel fan-out (MANDATORY — do not skip)
+
+**Single-agent sequential implementation is a banned anti-pattern.** Group the working list into dependency clusters by feature, then fan out clusters in parallel — **routing each cluster to the right builder by its REQ prefix**.
+
+Clustering rules:
+- SAME cluster if REQs touch the same page/component/layout (UI), the same controller/service/DB table (FN), the same `TechieRagBuilder`/embedding/`IConversationMemory` (RAG), or one depends on a type/contract the other defines.
+- DIFFERENT clusters if they share no files and no contract dependency.
+- A cluster is single-prefix where possible so it routes cleanly to one builder. A mixed feature (e.g. a settings page that saves to DB) splits into a UI cluster (REQ-UI) + an FN cluster (REQ-FN) with the FN one depending on the UI contract.
+
+Emit a one-block cluster table BEFORE fanning out, naming the builder per cluster:
+```
+Cluster A [trblazeui]: REQ-UI-1, REQ-UI-2  (Login page — mockup: docs/mockups/login.html)
+Cluster B [flow-master]: REQ-FN-3, REQ-FN-4  (Order pipeline)
+Cluster C [techierag]: REQ-RAG-1            (Doc-search RAG flow)
+Cluster D [flow-master]: REQ-NFR-1          (Logging middleware)
+```
+
+Then in ONE assistant turn, spawn the clusters in parallel:
+- **`[trblazeui]` clusters** — invoke `/trblazeui` as a sub-agent (Claude Code `/trblazeui …`, OpenCode `/trblazeui …`). The prompt MUST include: the cluster's REQ-UI IDs + acceptance verbatim from the checklist; **the mockup file(s) the cluster realizes + their component map** (build the screen to match the mockup — same TrBlazeUI controls, same layout); `docs/{AppName}-Coding-Standards.md` + field-prefix rule; `.trblazeui/TrBlazeUI-AI-Reference.md`; **the two standing rules verbatim (see below)**; tag each REQ's work with `[REQ-UI-N]` in the checklist Remarks (NEVER a git commit); log TrBlazeUI gaps to `docs/{AppName}-TrBlazeUI-Feedback.md` (one file per library); return `{ reqsImplemented[], filesChanged[], libraryIssues[] }`.
+- **`[techierag]` clusters** — invoke `/techierag` as a sub-agent. Prompt MUST include: REQ-RAG IDs + acceptance; `.techierag/TechieRag-AI-Reference.md`; coding standards; wire via `TechieRagBuilder` / `ITechieRag` (`IngestAsync`/`SearchAsync`/`AskAsync`/`ChatWithRagAsync`), `ITokenTracker` if an NFR needs it; unit tests in `tests/unit/Rag/`; **the two standing rules verbatim (see below)**; tag work `[REQ-RAG-N]` in the checklist Remarks (NEVER a git commit); log gaps to `docs/{AppName}-TechieRag-Feedback.md` (one file per library); return contract as above + `testsAdded[]`.
+- **`[flow-master]` clusters** — spawn one **builder subagent** per cluster: `tf-builder` if the harness registers it, otherwise the harness's general subagent (Claude Code: the `Agent` tool, `subagent_type=tf-builder|general-purpose`; OpenCode: the `task` tool, `subagent_type=tf-builder|general`). Prompt MUST include: REQ-FN/NFR IDs + acceptance; coding standards + field-prefix rule; architecture boundaries; **the two standing rules verbatim (see below)**; tag work `[REQ-FN-N]`/`[REQ-NFR-N]` in the checklist Remarks (NEVER a git commit) + unit tests in `tests/unit/`; log library gaps to the owning library file; return contract.
+
+**The two standing rules — paste into EVERY sub-agent prompt (library agents don't read `.tfcore/` tasks, so the rules reach them only through you):**
+1. *GIT IS MANUAL:* "NEVER run `git` or `gh` for any purpose — no commit, no `status`/`log`/`diff`/`grep`/`blame`. The harness denies it. Record your REQ IDs in the checklist Remarks, not in commits. Evidence for 'what changed' = the working-tree files you edited."
+2. *SMOKE IT YOURSELF:* "Before you return, run your changed feature once against the running app yourself — headless Playwright (WSL) / the Windows-MAUI bridge / the Appium bridge are already set up; 'can't run on Linux/WSL', 'it's MAUI', 'needs a GUI' are banned excuses (`.tfcore/tasks/_smoke-test-policy.md`). Confirm the data renders AND the screen looks right; use a documented test user from the UsageGuide/DB, never an invented one. Never ask the owner to run anything."
+
+A sub-agent that git-commits or returns un-smoked code is the orchestrator's failure — reject its return and re-prompt with the rules.
+
+**Head naming is fixed at scaffold time — the primary head carries the PRODUCT name.** The product's primary executable head project is named exactly `{AppName}` (`src/{AppName}/{AppName}.csproj`) — **NEVER `{AppName}.App`** (a meaningless suffix; banned, owner rule 2026-07-10). A single-head product's one head IS `{AppName}`. Secondary heads of a multi-head product take a *descriptive* dotted suffix (`{AppName}.Api`, `{AppName}.Desktop`); satellites keep their conventional names (`{AppName}.Core`, `{AppName}UI` RCL, `{AppName}.Core.Tests`). If the working tree already contains a `{AppName}.App`, do not propagate the name into new code/docs — log a rename REQ in the checklist (dir + `.csproj` + sln + namespaces) and build it.
+
+**Serilog is wired at scaffold time, not on request.** Whenever a cluster CREATES a new executable head (a web/API host, MAUI app, desktop app, console/CLI, background service), it wires Serilog file-based logging as part of the scaffold per coding-standards §Logging (rolling file sink under `logs/`, startup + unhandled-exception logging, `ILogger<T>` in app code) — even if no open REQ names logging. Day-1 BRDs carry a standing Observability NFR that split-brd turns into a `REQ-NFR-*` row; if this app's checklist predates that rule and has no logging REQ, wire it anyway and note it in the cluster's checklist Remarks. The owner never has to ask for logging.
+
+Wait for ALL sub-agents to return, then aggregate. The orchestrator owns the build + smoke + verifier handoff (§6–§7); sub-agents own per-cluster implementation only. **Cluster of size 1 still fans out.** Skip parallelism only if the entire working list is a single tight cluster — then do it inline and note "Single-cluster — implemented sequentially."
+
+### 4. Library issue logging (continue with workaround, do not stop)
+
+Gaps in TrBlazeUI → `docs/{AppName}-TrBlazeUI-Feedback.md` (TR-NNN); gaps in TechieRag → `docs/{AppName}-TechieRag-Feedback.md` (TR-RAG-NNN). Create from `.tfcore/templates/v4custom/app-library-feedback-tmpl.md` on first issue. One file PER library (separate teams — never combine). Schema: Severity / Repro / Expected / Actual / Encountered in / Workaround / Suggested fix. Workaround + log + continue — never stop the build for a library gap, never silently swallow it.
+
+### 4a. Specification-gap logging — the DESIGN miss (do not skip, do not stop)
+
+Library gaps go in the feedback files (§4). **Specification gaps go in `misses.jsonl`.** When a REQ you are building turns out to be unbuildable as written — no acceptance criteria, a screen with no mockup, two REQs that contradict each other, a behaviour the BRD plainly needed and never named — that is a **miss made in the design phase**, and this is the only place in the framework that can see it. The verifier cannot: by the time it runs, the gap has either been papered over or built wrongly.
+
+Do what you already do — pick the sensible reading, note it in the checklist Remark, and keep building. Then record it:
+
+```bash
+MID=$(bash .tfcore/utils/tf-emit.sh --next-miss-id)
+cat <<JSON | bash .tfcore/utils/tf-emit.sh misses
+{"kind":"miss","miss_id":"$MID","req_id":"REQ-FN-014","req_class":"FN",
+ "miss_class":"unspecified-gap","artifact":"brd","severity":"minor",
+ "why_missed":"missing-checklist-item",
+ "origin_phase":"split-brd","origin_agent":"analyst",
+ "origin_run_id":"<started of the split-brd/day1 run, from runs.jsonl>",
+ "found_by":"agent-review","found_phase":"build-phase",
+ "found_gate":null,"found_run_id":"<the §0 timestamp>","failure_class":null}
+JSON
+```
+
+- **`artifact`** names the deficient document: `brd` · `architecture` · `uidesign` (a screen with no mockup) · `checklist` (a REQ with no acceptance bullet).
+- **`miss_class`** is `unspecified-gap` for something never specified, `spec-contradiction` for two requirements that cannot both hold. If the spec was fine and the *previous build* got it wrong, that is `missed-requirement` / `partial-implementation` with `origin_phase:"build-phase"` instead.
+- **`req_id:null` is correct** when the gap is behaviour no REQ ever covered. Do not attach it to the nearest REQ to make the record look tidier — an unowned gap is a different and more interesting finding than a thin REQ.
+- **`why_missed`** (SCHEMA §5.5.6) — from this phase it is nearly always `missing-checklist-item` (nothing covered the behaviour) or `ambiguous-acceptance` (the criteria admitted two honest readings and you had to pick one). `dependency-not-declared` where the REQ needed something no document stated.
+- **`severity`** here is about the *product*, not about how much it slowed you down.
+- Run the `--open-miss` check first when the gap attaches to a REQ; skip it when `req_id` is `null`.
+
+This does not change what you do next: **log and continue.** A spec gap never stops a build, never becomes a question to the owner mid-pass, and never blocks the working list (§2b). It is a record, not a gate.
+
+### 5. Build (must PASS before self-smoke)
+
+Run the build using the **invocation ladder** at `.tfcore/templates/v4custom/build-invocation-ladder.md`. MANDATORY:
+- **Platform probe first** — read ladder §0. In OpenCode Docker, confirm `/usr/local/bin/winrun`, `TF_WINDOWS_APP_PATH`, and the mounted `/root/.nuget/NuGet/NuGet.Config`; prove the bridge with `winrun "dotnet --info"`. Do not probe direct `cmd.exe` in the container.
+- **Solution-scan second** — in OpenCode Docker, a solution containing a Windows MAUI head uses `winrun "dotnet build ..."`; a solution containing only standard .NET projects uses container `dotnet build`. Never install/check for `maui-tizen`; this image intentionally has no MAUI workloads.
+- **Workload errors are wrong-rung signals, not project blockers** — `NETSDK1178`, `Microsoft.iOS.Sdk missing`, `Workload ID … not recognized` → on WSL switch to rung #4; in OpenCode Docker use `winrun` for a Windows MAUI head, and never install a workload in the container. Do NOT log these as failures.
+- **Real compile errors** (CS####, missing source references) → fan out fix subagents (group by file) and retry.
+- Never accept "command not found" as a stop condition — that means wrong rung, not missing dotnet.
+
+### 6. Self-smoke — data + visual (MANDATORY — do not skip)
+
+**Follow `.tfcore/tasks/_smoke-test-policy.md` for this whole section.** Non-negotiables from it: (1) you run the smoke yourself — "can't run on Linux / it targets Windows / it's MAUI / Playwright needs a GUI / it's multi-service / data is present so it's fine" are BANNED excuses; the headless-Playwright + Windows/MAUI bridge are already set up (use rung #4 and verify-phase §3a before ever asking the user). (2) For any smoke needing a login, use a test account from `docs/{AppName}-UsageGuide.md` or the database — NEVER auto-create random smoke users; if none exists, ask the user to confirm before creating, then record it in the UsageGuide. (3) **"it runs" means the controls RENDER THEIR DATA *and* the screen LOOKS RIGHT** — a blank table is a failed smoke (RENDER-TRUTH) and so is a screen whose controls overlap / clip / sit off-viewport (VISUAL-TRUTH).
+
+**A green compiler is not proof the code works.** Self-smoke before chaining the verifier:
+
+1. Boot the app yourself via the build invocation ladder (local-only — never propose cloud deploy; see verify-phase.md §Local-only deployment policy). Bring up dependent services (DB/LLM/API) yourself in dependency order if it's a multi-service stack.
+2. Poll until ready (HTTP 200 or "Now listening on", up to 60s).
+3. For EACH REQ implemented this phase, run a **minimal smoke**, fanned out across parallel subagents (one per cluster):
+   - UI / page REQ → Playwright: page reachable AND its top-level control **renders its data** (rows present and non-empty, chart non-empty) AND the screen passes the **visual check** — no sibling-control bounding-box overlap, every control in-viewport and non-zero size, at desktop + a mobile width; capture a screenshot and eyeball it; where a mockup exists, it should match the mockup's layout.
+   - API REQ → request the endpoint, expect `ok()`; for RAG: ingest→200, search→non-empty, chat→non-empty answer.
+   - Pure backend REQ → run its unit test (`~/.dotnet/dotnet test --filter "FullyQualifiedName~{TypeName}"`).
+4. Kill the boot process; confirm the port is free.
+5. **Write the smoke results into the Requirements Status table** of `docs/{AppName}-Checklist.md` — do NOT create a `docs/qa/*-smoke-*.md` file. Per REQ set Status (`Implemented` if smoke PASS pending verifier; `FAIL`/`PARTIAL`/`Needs re-verify` otherwise), `%`, and a dated Remark (visual failures prefixed `⚠ visual:`). Playwright screenshots stay in `tests/.artifacts/`, and any throwaway smoke script you wrote stays in `tests/.artifacts/harness/` (both gitignored — **never** a repo-root `test-results/`, `test-results-<slug>/` or `scripts-<slug>/`, and never inside the project's own tracked `scripts/`; see `verify-phase.md` §1 artifact-location rule, which binds self-smokes too); only the one-line outcome goes in Remarks.
+
+**If any smoke FAILed (data or visual):** loop back into FIX mode (§2a) on the failed REQs — route layout/overlap failures back to the `[trblazeui]` builder. Do NOT chain to the verifier with known smoke failures.
+
+**If app failed to boot:** apply the local-fallback flow from verify-phase.md §3a (escalate, bring services up yourself, ask the user to run it only as a last resort) — never propose cloud deploy.
+
+### 6b. Chain verifier (only after smoke is clean)
+
+- **How to chain:** read `.tfcore/tasks/verify-phase.md` and execute it inline in THIS session with scope `all` — the scope is known, so skip its §0 question. (Do not hand back to the user; the chain is automatic.)
+- **Chaining = EXECUTING, not summarizing.** "Execute verify-phase inline" means actually performing its §1–§7 steps in this session — boot per the ladder, generate + run the scoped tests, apply §4a data-render + §4b visual-truth, write the run ledger `docs/.last-verify.json` (verify-phase §6), THEN record verdicts. Your §6a self-smoke is NOT a substitute, however thorough it felt — smoke results cap at `Implemented`. **The build orchestrator NEVER writes `Verified` from its own observations**; a `Verified` status exists only downstream of an executed verify-phase run. This is enforced mechanically: the PreToolUse hook `.tfcore/hooks/guard-verify.sh` blocks any checklist write that introduces `Verified` without a same-day run ledger. If you are about to set a REQ to `Verified` and you have not executed verify-phase this session, STOP — you are self-attesting (the exact 2026-07-09 TrSetup failure this rule exists to prevent).
+- Output: the verifier writes each REQ's verdict (Status / % / Remarks) **into the Requirements Status table** of `docs/{AppName}-Checklist.md` — no dated coverage file. It applies BOTH the data render gate (§4a) AND the visual-truth gate (§4b); a REQ is `Verified` only if acceptance passes AND its controls render data AND the screen looks right.
+- The verifier ALSO runs the standards-compliance grep checks from `docs/{AppName}-Coding-Standards.md` §"Enforcement". Violations get noted in the offending REQ's Remarks (or a standards row) and reflected in PROJECT-STATUS standards-compliance.
+- The verifier reads the current Status table as its baseline — REQs already `Verified` re-confirm fast; it prioritizes the rest.
+
+### 6c. FIX loop after the verifier
+
+If the verifier reports `FAIL` / `Needs re-verify` rows:
+
+- **YOLO / goal mode ON** (`bash .tfcore/utils/tf-yolo.sh is-on` exits 0, or `TF_YOLO=1`, or the session is a `/goal` / `tf-goal.sh` run): **do not hand back.** Re-enter §2a — it detects FIX mode on exactly those rows — fan the repairs out (§3; layout/overlap → `[trblazeui]`), rebuild (§5), re-smoke (§6), re-chain the verifier (§6b) on the same scope. Repeat until every row is terminal or `Blocked`, **up to 5 FIX cycles per pass**; each cycle emits its own `runs.jsonl` record with `"mode":"fix"` (§7a). A row that is still failing after 5 cycles is marked `FAIL` with a Remark naming the cycle count and the last observed defect, and goes into PROJECT-STATUS "Known blockers" — that is the only way a FAIL row survives a YOLO pass.
+- **YOLO OFF:** return to the user with the matrix + message: "Fix the flagged REQ-* items by re-running `*build-phase {AppName}` — it detects FIX mode and fans out repair subagents (layout fixes route to trblazeui). `Blocked` (library-gap) items pass through." (This — FIX mode on verifier failures — is the **only** situation where "run build-phase again" is a legitimate next step; see §2b.)
+
+### 7. FINAL GATE — update PROJECT-STATUS.md (MANDATORY, non-skippable)
+
+**You are NOT done until this is written. Updating PROJECT-STATUS — BOTH `PROJECT-STATUS.md` AND re-rendered `PROJECT-STATUS.html` — is the LAST action of every phase, every time; a markdown-only update is incomplete (the owner reads the HTML). Never report completion without both.** (Hard framework rule; see `.tfcore/tasks/_status-update-gate.md`.)
+
+- **Build status (always update):** `last_verified_build: PASS` and `last_verified_date: {today YYYY-MM-DD}`. If the build failed and you somehow advanced anyway, set `FAIL` and add to "Known blockers".
+- **Open requirements:** sync the checkbox list to the checklist Status table — anything not `Verified` stays open.
+- **Next command — the Build → Verify → Handoff ladder, gated on the weakest open REQ** (per `_status-update-gate.md` item 5; do NOT freelance to `*verify all` just because you built something this pass):
+  - **Any REQ still unbuilt** (`Planned`/`In Progress`/`PARTIAL`/`NOT-IMPLEMENTED`, or open + not implemented) → keep phase `Build`, next command = `/TechieFlow:agents:flow-master *build-phase {AppName}` (OpenCode: `/flow-master *build-phase {AppName}`) naming the open REQ IDs. Building isn't finished, so **build is next — not verify**, even if other REQs you just wired now want verification. This includes REQs that are built but **`NOT-OBSERVABLE` for lack of a test/harness** — writing that test is build work (`*build-phase` adds unit tests), so build still leads until the verifier has something to assert. **But read §2b before you write this line:** if the unbuilt REQs are unbuilt because *this pass stopped early*, you are not at the gate yet — go back to §3 and build them. This bullet describes a state the owner finds after a `Blocked`/owner-gated remainder or a crashed session, not an ending you choose.
+  - **All REQs built AND observable (≥ `Implemented`, with a test/route the verifier can exercise) but some not `Verified`** → phase `Verify`, next command = `/TechieFlow:agents:verifier *verify all {AppName}` (OpenCode: `/flow-verifier *verify all {AppName}`) (or narrowest scope).
+  - **All agent-verifiable REQs terminal, but open rows remain that are documented OWNER-RUN UAT** (external/host-bound/destructive — the verifier cannot exercise them from this machine) → phase `UAT`, next command = the owner-run pointer at `docs/{AppName}-UsageGuide.md §"UAT plan"` naming the open REQ IDs. **Do NOT suggest `*handoff-phase` — not even as "optional" —** if a READY-FOR-UAT handoff already ran this cycle (check the Verification log); it only leads (once) when it has never run for this cycle, because it produces the UAT bundle. Never say "nothing left" / "done" / propose `Released` while non-terminal rows remain — `Released` is the OWNER's call after UAT (_status-update-gate.md item 5).
+  - **All REQs terminal** (`Verified`/`Done (pre-existing)`/`N/A`; `Blocked`-by-library counts as pass-through) → phase `Handoff`, next command = `/TechieFlow:agents:flow-master *handoff-phase {AppName}` (OpenCode: `/flow-master *handoff-phase {AppName}`) — or, if handoff already ran, the project waits on the owner to set `Released`.
+- Log a verification-log row (Status table column → `docs/{AppName}-Checklist.md#requirements-status`).
+- Update "Library feedback summary" counts and "Standards compliance".
+
+### 7a. Emit the run record
+
+Same turn as the status gate, right after it. Doctrine + the ten constraints: `.tfcore/tasks/_metrics-emit-gate.md`. Schema: `.tfcore/telemetry/SCHEMA.md` §2.
+
+```bash
+cat <<'JSON' | bash .tfcore/utils/tf-emit.sh runs
+{"kind":"run","app":"{AppName}","cmd":"build-phase","mode":"build",
+ "started":"<the §0 timestamp>","ended":"<now>","duration_s":<n>,
+ "reqs_touched":["REQ-UI-004","REQ-FN-011"],"reqs_count":2,
+ "subagents":["trblazeui"],"files_written":14,"build_result":"pass"}
+JSON
+```
+
+- **`mode` is the rework metric — get it right.** `"fix"` when §2a detected FIX mode (re-entry over `FAIL`/`Needs re-verify` rows), `"build"` on a FRESH pass. The ratio of the two is how the framework measures how much work is rework; a mislabelled run corrupts it silently.
+- `subagents` = which of `trblazeui` / `techierag` / `general-purpose` you actually fanned out to this pass. Empty array if you built everything yourself.
+- `files_written` is a count you already know — **do not shell out to compute it.**
+- `build_result` = `pass` / `fail` / `not-run` — honestly, including when the phase ended badly.
+- `reqs_touched` carries **REQ IDs only**. Never requirement text (constraint 7).
+
+The verify pass chained in §6b emits its own `gates.jsonl` records **and its own `misses.jsonl` records** (verify-phase §6a) — do not emit those yourself; the verifier owns both, exactly as it owns the `Verified` verdict. The only misses this task writes are the §4a **specification gaps**, which the verifier structurally cannot see.
+
+**In FIX mode (§2a), also close the misses you repaired.** For each REQ you re-entered that had an open miss, emit a `miss-fix` after this run record exists — it is the run record's `started` that carries the token window the fix cost is read from:
+
+```bash
+MID=$(bash .tfcore/utils/tf-emit.sh --open-miss REQ-UI-009 | cut -d' ' -f1)
+[ -n "$MID" ] && FA=$(bash .tfcore/utils/tf-emit.sh --next-fix-attempt "$MID") && \
+cat <<JSON | bash .tfcore/utils/tf-emit.sh misses
+{"kind":"miss-fix","miss_id":"$MID","req_id":"REQ-UI-009",
+ "fix_run_id":"<the §0 timestamp — this run's started>","fix_cmd":"build-phase",
+ "fix_attempt":$FA,"verdict_after":"<the verifier's verdict for this REQ>","reopened":false}
+JSON
+```
+
+`verdict_after` is **the verifier's verdict, not your opinion of the fix** — `Verified` only if §6b actually produced it. A miss closed on a builder's self-assessment is the same failure as a self-attested `Verified`, one stream over. Write no token or cost fields: the emitter copies them from the run you just named (constraint 10).
+
+**Telemetry has no veto.** If the emit fails, the phase still succeeded: do not retry, do not diagnose, do not mention it.
+
+## Output Checklist
+
+- [ ] **ALL open `REQ-UI/FN/RAG/NFR-*` from the checklist implemented in THIS pass (§2b) — no "run build-phase again for the remaining REQs" ending; every working-list row ≥ `Implemented` or a logged `Blocked`/owner-gated blocker** (terminal rows untouched)
+- [ ] Work tagged `[REQ-*]` in the checklist Remarks (never a commit — git is manual); unit tests added
+- [ ] **YOLO / goal mode: FIX loop ran automatically on verifier FAIL rows (§6c, ≤5 cycles); sentinel `tf-yolo.sh done` written only if this was the goal's last phase**
+- [ ] `dotnet build` passes
+- [ ] **Cluster table emitted naming the builder per cluster; sub-agents (trblazeui / techierag / flow-master) fanned out in parallel** (or single-cluster note)
+- [ ] UI clusters built to match the approved mockups
+- [ ] **Self-smoke ran (agent ran it — no excuses); DATA-render AND VISUAL checks applied; results in the checklist Status table** (no `docs/qa/*.md` file) — per `_smoke-test-policy.md`
+- [ ] Smoke used a documented/existing test user (UsageGuide table or DB) — NO random smoke-user auto-created
+- [ ] **Verifier verdicts written into the checklist Status table** (Status / % / Remarks per REQ)
+- [ ] Library issues (if any) logged to the owning per-library file
+- [ ] Standards-compliance greps clean (or violations noted)
+- [ ] **PROJECT-STATUS.md updated — FINAL GATE (phase, next command, open reqs, log row) + re-rendered HTML**
+- [ ] **`runs.jsonl` record emitted (§7a) with the correct `mode` (build vs fix)**
+- [ ] Specification gaps hit during the pass logged as `misses.jsonl` `unspecified-gap` records (§4a) — logged and continued, never a stop
+- [ ] FIX mode only: a `miss-fix` emitted per re-entered REQ that had an open miss, carrying the **verifier's** verdict (§7a)