@techierathore/techieflow 1.0.2 → 1.0.4

package/.tfcore/templates/v4custom/app-brd-tmpl.md

@@ -1,204 +1,128 @@
-# {AppName} — Business Requirements
-
-<!-- AGENT-ONLY AUTHORING NOTES. Everything in this comment is an instruction to the DRAFTING
-     AGENT, not content for the document's human reader. Carry it into the generated document
-     ONLY as this HTML comment (or drop it entirely) — NEVER as visible text: the owner reads
-     the rendered HTML and must not see authoring instructions (generate-html.md strips any
-     that leaked from older templates).
-
-  STABLE IDS: every requirement has a BRD-{N} ID. IDs are append-only across revisions.
-
-  DEPTH MANDATE (read before drafting): this is a HUMAN document, read as rendered HTML by the
-  product owner. It is NOT the coding checklist (that's docs/{AppName}-Checklist.md / split-brd
-  output). One-line entries belong ONLY in §10's requirements ledger. Every other section is
-  full prose, tables, and Mermaid diagrams. §9 Feature catalog is the heart of the document —
-  one detailed subsection per feature, with screens, workflows, and a diagram wherever the flow
-  is non-trivial. When harvesting existing source docs, this document must be an
-  information-preserving SUPERSET of their requirements content: carry their tables, matrices,
-  screen inventories, and menus forward (updated, not summarized away). If a reader of the old
-  doc would miss something in this one, the draft is wrong.
-
-  MERMAID MANDATE: every diagram MUST follow the authoring rules in
-  .tfcore/templates/v4custom/html-render-shell.md §5.5 — quote every node/edge/subgraph label
-  (A["Order Service (v2)"], not A[Order Service (v2)]) and never use `end` as a node id.
-  Unquoted special characters ( ( ) / & : , … ) in flowchart labels are the #1 cause of
-  "Syntax error" diagrams in the rendered HTML.
+<!-- tf-schema
+doc: brd
+file: docs/{App}-BRD.md
+header: App, Kind, Size, Stack answer set, Status, Date
+section: Summary | required | max 200
+section: Scope | required
+section: Users and roles | required
+section: Screens and flow | required
+section: Requirements | required
+section: Non-functional requirements | required
+section: Development status | required
+section: Context diagram | optional-small
+section: Constraints and assumptions | optional-small
+section: Risks | optional-small
+section: Glossary | optional
+budget: S 6000 8000 | M 10000 15000 | L 10000 15000
+rule: brd-ledger
+rule: screens-table
+rule: mockup-links
 -->
+<!-- Authoring notes (agent only; never visible text).
+     Sections and order are fixed by the schema above; tf-doc-check.sh refuses the document otherwise.
+     Word counts exclude code blocks and comments. The budget is met by shorter prose, never by dropping
+     a screen, a field or a requirement. BRD ids are append-only and never renumbered.
+     Size and requirement cap: Small up to 10 screens, one role, 50 requirements; Medium up to 20 screens,
+     100 requirements; Large is split into phases, each phase its own BRD. Every routed page is a screen;
+     dialogs, tabs and panels are regions of their page and are listed under it.
+     Large project: one BRD per phase, phase 1 in docs/{App}-BRD.md, phase n in docs/{App}-Pn-BRD.md; the
+     header gains a row "| Phase | n of m |", Size is the phase's own size (Small or Medium), and BRD-N
+     runs on from the previous phase's last id. The phase plan is docs/{App}-Phases.md.
+     Mermaid: quote every label (A["Order (v2)"]); never use `end` as a node id. -->
 
+# {App} — Business Requirements
 
-## Table of Contents
-
-<!-- Auto-maintained by the analyst/day-1 tasks. Use the slug rule from .tfcore/templates/v4custom/html-render-shell.md §1 so links work in both MD and rendered HTML. Update this list whenever you add/rename a section. List each `### F-…` catalog entry as an H3 sub-entry under Feature catalog. -->
-
-1. [Executive summary](#executive-summary)
-2. [Business objectives](#business-objectives)
-3. [Scope](#scope)
-4. [Development status](#development-status)
-5. [Stakeholders / users](#stakeholders-users)
-6. [Context diagram](#context-diagram)
-7. [User journey — primary use case](#user-journey-primary-use-case)
-8. [Component sketch](#component-sketch)
-9. [Feature catalog](#feature-catalog)
-10. [Functional requirements (BRD ledger)](#functional-requirements-brd-ledger)
-11. [Non-functional requirements](#non-functional-requirements)
-12. [Constraints & assumptions](#constraints-assumptions)
-13. [Success metrics](#success-metrics)
-14. [Risks](#risks)
-15. [Glossary](#glossary)
-
-## 1. Executive summary
-<2-3 paragraphs: what we're building/changing and why it matters.>
-
-## 2. Business objectives
-- <measurable objective 1>
-- <measurable objective 2>
-
-## 3. Scope
-**In scope:** …
-**Out of scope (explicit):** …
-
-## 4. Development status
-
-<!-- SNAPSHOT (point-in-time) of what is BUILT vs PENDING, at the feature level — the first thing a
-     reader of an existing app wants to know. This is a HUMAN summary, NOT a competing source of truth:
-     the LIVE per-requirement status lives in PROJECT-STATUS.md + the one checklist's
-     "Requirements Status" table. Do NOT duplicate per-REQ status here — one row per feature only.
-       • Brownfield: fill from the migrated dev-plan and/or the code scan (what actually compiles/runs).
-         Mirror the phase tags used in the checklists.
-       • Greenfield: this is the build ROADMAP — every row is "Planned" with its target phase.
-     One row per §9 Feature-catalog F-code; group/order by phase. Keep the as-of date honest.
-     AUTO-MAINTAINED after day-1: the status gate (every build/verify/handoff phase) and
-     *refresh-status re-derive this table from the checklists and re-render the HTML, so it
-     tracks reality without manual edits — see _status-update-gate.md item 9. -->
-
-**Snapshot as of {YYYY-MM-DD}.** Live, per-requirement status: see `PROJECT-STATUS.md` and the **Requirements Status** table in `docs/{AppName}-Checklist.md`.
-
-| Feature (F-code) | Phase | Status | % | Notes |
-|------------------|-------|--------|---|-------|
-| F-{CODE}: {name} | {0 / 1 / 2 … or MVP} | Done | 100 | {what works} |
-| F-{CODE}: {name} | {phase} | Partial | {0–100} | {what's done / what's left} |
-| F-{CODE}: {name} | {phase} | Planned | 0 | {not started} |
-
-**Legend:** **Done** = shipped & working · **In progress** = actively being built · **Partial** = some sub-features done, others pending · **Planned** = not started. (Maps to the checklist's `Done (pre-existing)` / `In Progress` / `PARTIAL` / `Not Started`.)
-
-## 5. Stakeholders / users
-<!-- Full persona detail, not just a 2-row table. For each persona: role mapping (if an external auth/licensing system is involved), responsibilities, key screens, registration/onboarding path. If the app has license tiers / feature gating, include the full license & feature matrix here or as its own H2 (and add it to the TOC). -->
-| Role | Needs |
-|------|-------|
-| End user | … |
-| Admin    | … |
-
-## 6. Context diagram
-```mermaid
-flowchart LR
-  User(["End User"]) --> App["{AppName}"]
-  App --> DB[("Database")]
-  App --> LLM[/"LLM Provider"/]
-```
+| | |
+|---|---|
+| App | {App} |
+| Kind | app or library |
+| Size | Small, Medium or Large |
+| Stack answer set | {name of the answer set, or "none"} |
+| Status | Draft, Approved |
+| Date | {YYYY-MM-DD} |
 
-## 7. User journey — primary use case
-```mermaid
-sequenceDiagram
-  actor U as User
-  participant W as Web UI
-  participant A as App API
-  U->>W: action
-  W->>A: request
-  A-->>W: response
-  W-->>U: result
-```
+## 1. Summary
 
-## 8. Component sketch
-```mermaid
-flowchart TB
-  UI["Blazor UI — TrBlazeUI"] --> API["ASP.NET API"]
-  API --> SQL[("SQL")]
-  API --> Rag["RAG — TechieRag"]
-  Rag --> Vec[("Vector store")]
-```
+{What it is, for whom, why it exists. At most 200 words.}
+
+## 2. Scope
+
+**In:**
+- {…}
+
+**Out:**
+- {…}
+
+## 3. Users and roles
+
+| Role | Who they are | What they need |
+|---|---|---|
+| {Role} | {…} | {…} |
+
+## 4. Screens and flow
 
-## 9. Feature catalog
+One row per routed page. A dialog is a row under its parent screen with `on /route` in the Route column; it is not counted as a screen.
 
-<!-- THE HUMAN-READABLE HEART OF THE BRD. One `### F-{CODE}: {Name}` subsection per
-     feature / capability area. A real app typically has 8–25 entries; depth scales with
-     the app, NOT with a template quota. Repeat the skeleton below per feature.
-     Per feature include, where applicable:
-       - personas + phase/priority
-       - 1-2 paragraphs of what/why
-       - screens & routes table
-       - workflow / processing steps (numbered), inputs → outputs
-       - a Mermaid diagram for any multi-step or multi-actor flow (flowchart or
-         sequenceDiagram) — generic features (simple CRUD lists) may skip the diagram
-       - the BRD-N IDs this feature owns (forward links into §10)
-     Every F-code here MUST appear as a row in the §4 Development status table. -->
+| Screen | Route | Role | Mockup | Fields |
+|---|---|---|---|---|
+| {Screen name} | `/route` | {Role} | [mockup](mockups/{screen-slug}.html) | {field, field, field} |
+| {Dialog name} (dialog) | on `/route` | {Role} | [mockup](mockups/{screen-slug}.html) | {field, field} |
 
-### F-{CODE}: {Feature name}
+**Primary journey:**
+1. {The user opens … and …}
+2. {…}
 
-**Personas:** <who uses it> · **Phase:** <0/1/2/… or MVP/Later>
+## 5. Requirements
 
-<1-2 paragraphs: what this feature does and why it exists.>
+One item per thing the verifier will test. Each names its screen, links the mockup, and states its acceptance in the form the checklist will carry. Items are grouped under a `###` heading per screen that opens with one plain sentence saying what the screen does. A title is everyday words; an acceptance line is at most 30 words, target 20, and holds one behaviour: a line that bundles steps ("slots shown; Enter advances; empties dropped; a timer starts") is split into one item each (owner, 2026-09-06).
 
-| Screen | Route | Description |
-|--------|-------|-------------|
-| … | `/…` | … |
+### {Screen name}
 
-**Workflow:**
-1. <step>
-2. <step>
+{One plain sentence: what this screen does, for whom.}
+
+- **BRD-1** — {Title}. *Screen:* {Screen name} · *Mockup:* [mockup](mockups/{screen-slug}.html)
+  - *Acceptance:* When {actor} {does what} on {screen}, then {a result a browser robot can observe}.
+- **BRD-2** — {Title}. *Screen:* {Screen name} · *Mockup:* [mockup](mockups/{screen-slug}.html)
+  - *Acceptance:* When …, then ….
+
+## 6. Non-functional requirements
+
+| Id | Area | Requirement | Measure |
+|---|---|---|---|
+| BRD-{N} | Performance | {…} | perf-budget: p95 load <= 2000ms @ concurrency 1 |
+| BRD-{N} | Security | {…} | {…} |
+| BRD-{N} | Logging | {from the Stack answer set} | {…} |
+
+The `perf-budget:` measure is machine-read by the verifier, in exactly this form: `perf-budget: <p50|p95|max> <ttfb|load> <= <N>ms [@ concurrency <N>]`. Write one only where the owner stated a number.
+
+## 7. Development status
+
+Written by the status gate after every build, verify and handoff; not by hand.
+
+**Snapshot as of {YYYY-MM-DD}.** Live per-requirement status: `PROJECT-STATUS.md` and the Requirements Status table in `docs/{App}-Checklist.md`.
+
+| Screen | Requirements | Verified | Open | Status |
+|---|---|---|---|---|
+| {Screen} | {n} | {n} | {n} | Planned, In progress, Partial, Done |
+
+## 8. Context diagram
 
 ```mermaid
 flowchart LR
-  A["input"] --> B{"decision"} --> C["output"]
+  User(["User"]) --> App["{App}"]
+  App --> DB[("Database")]
 ```
 
-**Requirements:** BRD-x, BRD-y (see §10)
-
-## 10. Functional requirements (BRD ledger)
-
-<!-- The machine-traceable ledger consumed by *split-brd and the coding pipeline.
-     One line per discrete capability, `<actor> can <action>` or `system shall <behavior>`.
-     Each line names its catalog feature: `(F-CODE)`. The count scales with the app —
-     one BRD per capability, NEVER merge capabilities to keep the list short. -->
-
-- **BRD-1** — <one-line requirement> *(F-{CODE})*
-- **BRD-2** — <one-line requirement> *(F-{CODE})*
-
-## 11. Non-functional requirements
-<!-- Keep the BRD-N IDs, but give each NFR its target table when there are concrete numbers
-     (latency, uptime, concurrency, import throughput), as a human reader expects.
-     The Observability/logging NFR below is a TechieFlow STANDING requirement — it appears in
-     EVERY .NET app's BRD (web, API, MAUI, desktop, console, background service), never gets
-     dropped, and split-brd turns it into a REQ-NFR row like any other NFR.
-
-     PERFORMANCE — the `perf-budget:` line is MACHINE-READ. verify-phase §4c grades a REQ on
-     speed if and ONLY if it carries one, in exactly this grammar:
-         perf-budget: <p50|p95|max> <ttfb|load> <= <N>ms [@ concurrency <N>]
-     Omit it and the perf gate simply never fires for that REQ — which is the correct outcome
-     when there is no agreed number. Do NOT invent a budget to make the row look complete: a
-     threshold nobody agreed to produces failures nobody asked for, and the first false failure
-     is the moment gate verdicts stop being believed. Write one only where the owner states it.
-     Prose like "should feel fast" is not a budget and is deliberately not gradeable. -->
-- **BRD-N** — Performance: …
-      <!-- e.g.  Public pages stay responsive under normal load.
-                 perf-budget: p95 load <= 2000ms @ concurrency 1
-                 perf-budget: p95 ttfb <= 500ms @ concurrency 50   -->
-
-- **BRD-N+1** — Security: …
-- **BRD-N+2** — Accessibility: …
-- **BRD-N+3** — Observability: Serilog file-based logging in every executable head — rolling file sink under `logs/`, wired at startup, unhandled exceptions logged (see Coding Standards §Logging).
-
-## 12. Constraints & assumptions
-- …
-
-## 13. Success metrics
-- …
-
-## 14. Risks
+## 9. Constraints and assumptions
+
+- {…}
+
+## 10. Risks
+
 | Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+| {…} | {…} | {…} | {…} |
 
-## 15. Glossary
-- TrBlazeUI, TechieRag, REQ-UI-*, REQ-FN-*, REQ-RAG-*, REQ-NFR-*
+## 11. Glossary
 
----
-Last updated: {YYYY-MM-DD}
-Highest BRD ID: BRD-{N}
+- {Term} — {meaning}

package/.tfcore/templates/v4custom/app-brief-tmpl.md

@@ -0,0 +1,65 @@
+<!-- tf-schema
+doc: brief
+file: docs/{App}-Brief.md
+header: App, Date
+section: What it is | required | max 150
+section: Who it is for | required | max 150
+section: Must do | required
+section: Out of scope | required | max 150
+section: Open questions | optional | max 150
+rule: brief-must-do
+rule: no-glossary
+target-lines: 60
+max-lines: 120
+-->
+<!-- Authoring notes (agent only; never visible text).
+
+     The brief is the input to day-1: `*day1-greenfield` and `*day1-brownfield` read it
+     and turn it into the Architecture, the BRD and the mockups. Its whole job is to be
+     ONE PAGE the owner can read and correct in two minutes, before anything expensive
+     is built on it.
+
+     It replaced a 221-line inherited template (2026-09-08) whose twelve sections —
+     executive summary, problem statement, proposed solution, goals and metrics, KPIs,
+     post-MVP vision, expansion opportunities — produced a document nobody read and
+     nothing checked. What the framework's own review says a brief is: "a one-page
+     brief: product, users, must-do, out of scope". That is what this template holds.
+
+     Each "Must do" line becomes one or more BRD items at day-1, so write them as
+     things the product does, one per line, numbered. Not features to build: outcomes
+     a user gets. If a line needs a paragraph to explain it, it is two lines.
+
+     "Open questions" is where a decision the owner has not taken goes, so day-1 asks
+     rather than assumes. An empty brief with three honest open questions is worth more
+     than a full one built on guesses. -->
+
+# {App} — Brief
+
+| | |
+|---|---|
+| App | {App} |
+| Date | {YYYY-MM-DD} |
+
+## What it is
+
+{Two or three sentences, at most 150 words. What the product does, in the words you
+would use to a person who has never heard of it. No technology.}
+
+## Who it is for
+
+{Who uses it and what they are trying to get done. Name each role. At most 150 words.}
+
+## Must do
+
+1. {One thing the product does, as an outcome a user gets.}
+2. {Another.}
+3. {Another.}
+
+## Out of scope
+
+{What this is deliberately not doing, so day-1 does not build it. At most 150 words.}
+
+## Open questions
+
+{A decision not yet taken, one per line, so day-1 asks instead of assuming. Delete the
+section when there are none.}

package/.tfcore/templates/v4custom/app-checklist-tmpl.md

@@ -1,90 +1,65 @@
-# {AppName} — Checklist
-
-## Table of Contents
-
-<!-- Auto-maintained. Slug rule: .tfcore/templates/v4custom/html-render-shell.md §1. Update when sections change. As pages grow, list each `### Page: ...` as an H3 sub-entry under "UI / Pages". -->
-
-1. [Goal](#goal)
-2. [Requirements Status](#requirements-status)
-3. [UI / Pages](#ui--pages)
-4. [Functional requirements](#functional-requirements)
-5. [RAG / AI requirements (→ /techierag)](#rag-ai-requirements-techierag)
-6. [Non-functional](#non-functional)
+<!-- tf-schema
+doc: checklist
+file: docs/{App}-Checklist.md
+header: App, Size
+section: Goal | required | max 120
+section: Requirements Status | required
+rule: checklist-rows
+-->
+<!-- Authoring notes (agent only). An agent document: never rendered, never reviewed by the owner.
+     Sections: Goal, Requirements Status (the one table), then one section per page or group holding
+     the detail entries. No other sections: bugs, UAT findings and feedback go to the misses stream.
+     Row rules (tf-doc-check.sh refuses the file otherwise):
+       - header exactly | ID | Requirement | Status | % | Remarks | Details |
+       - ID is REQ-UI-, REQ-FN-, REQ-RAG- or REQ-NFR- plus three digits; row count within the size cap
+       - Status is one of the fixed values; Verified is written only by a verify run (hook)
+       - % is 0, 25, 50, 75 or 100
+       - Details links to the entry's anchor in this file
+       - every entry names its BRD-N item; UI rows link a mockup that exists
+       - exactly one acceptance line per entry: "When <actor> <does what> on <screen>, then <observable result>"
+         ("Given …," may precede it; NFR rows name the measurement instead of a screen); at most 30 words,
+         target 20, one behaviour per row (a bundled line is split into rows); the title is everyday words
+       - a perf-budget line is copied verbatim from the BRD, never invented:
+         perf-budget: <p50|p95|max> <ttfb|load> <= <N>ms [@ concurrency <N>]
+       - Remarks holds the current state only, at most 60 words; history lives in gates.jsonl and misses.jsonl
+     Prefix routing: REQ-UI- built from the mockups by the UI sub-agent; REQ-RAG- by the RAG sub-agent;
+     REQ-FN- and REQ-NFR- by the build phase. `*verify ui|functional|all` filters this table by prefix.
+     Large project: one checklist per phase (docs/{App}-Checklist.md, docs/{App}-P2-Checklist.md, …), a
+     header row "| Phase | n of m |", REQ numbers running on across phases. tf-split-brd.sh does this. -->
+
+# {App} — Checklist
+
+| | |
+|---|---|
+| App | {App} |
+| Size | Small, Medium or Large |
 
 ## Goal
-<one paragraph; ties back to BRD §1. This single checklist is the whole app's work list — UI, functional, RAG, and NFR requirements live together, distinguished only by their REQ prefix.>
 
-## Requirements Status
+{One paragraph tying back to the BRD summary. This single checklist is the whole work list.}
 
-<!-- ============================================================
-     SINGLE SOURCE OF TRUTH for the WHOLE app (UI + functional +
-     RAG + NFR). There is exactly ONE checklist per app — the two
-     former files (UI-Checklist / Functional-Checklist) were merged
-     into this one. Build, self-smoke, and the verifier ALL write
-     their outcomes into THIS table — never into a separate dated
-     results file. One row per REQ, grouped by prefix:
-       REQ-UI-*  → built by /trblazeui (from the mockups)
-       REQ-FN-*  → built by the unified build-phase
-       REQ-RAG-* → built by /techierag
-       REQ-NFR-* → built by the unified build-phase
-     Scopes (`*verify ui|functional|all`) filter THIS table by
-     prefix — they do NOT pick a separate file. Update Status + % +
-     Remarks every time work (implementation, smoke, or verify)
-     touches the REQ. Bugs and change notes live in the Remarks
-     column, NOT in docs/qa/*.md.
-     ============================================================ -->
+## Requirements Status
 
 | ID | Requirement | Status | % | Remarks | Details |
 |----|-------------|--------|---|---------|---------|
-| REQ-UI-001  | Dashboard top nav | Not Started | 0% | — | [view](#d-req-ui-001) |
-| REQ-FN-001  | <short name> | Not Started | 0% | — | [view](#d-req-fn-001) |
-| REQ-RAG-001 | <short name> | Not Started | 0% | — | [view](#d-req-rag-001) |
-| REQ-NFR-001 | <short name> | Not Started | 0% | — | [view](#d-req-nfr-001) |
-
-**Status values:** `Not Started` · `In Progress` · `Implemented` (code done, not yet verified) · `Verified` (self-smoke or verifier PASS — acceptance AND data-render AND visual gates all pass) · `Done (pre-existing)` (migrated from an earlier dev plan as already complete — build agents must NOT rebuild; terminal like `Verified`) · `Needs re-verify` (a defect or change was logged — must be re-run before it can return to `Verified`) · `PARTIAL` (some acceptance unmet — say what in Remarks) · `FAIL` (verifier ran and failed — bug in Remarks) · `Blocked` (external/library gap — link the TR-/TR-RAG- entry in Remarks) · `N/A`.
-
-**% guide:** `0` not started · `25` scaffolded · `50` in progress · `75` implemented-unverified · `100` verified.
-
-**Remarks:** date + what was done / what is missing / bug or library reference. This is the home for bugs and change notes — do not spawn a separate file. Visual-gate failures are prefixed `⚠ visual:`; security findings `⚠ SECURITY`.
-
-## UI / Pages
+| REQ-UI-001 | {short name} | Not Started | 0% | — | [view](#d-req-ui-001) |
+| REQ-FN-001 | {short name} | Not Started | 0% | — | [view](#d-req-fn-001) |
+| REQ-NFR-001 | {short name} | Not Started | 0% | — | [view](#d-req-nfr-001) |
 
-<!-- Each REQ carries an explicit `<a id="d-REQ-ID">` anchor (lowercase) so the
-     Details column above links straight to it in both Markdown and rendered HTML.
-     UI REQs are built by /trblazeui from the approved mockups (docs/{AppName}-UIDesign.md
-     + docs/mockups/*.html); cite the mockup screen each REQ realizes.
+**Status values:** `Not Started` · `In Progress` · `Implemented` · `Verified` · `Done (pre-existing)` · `Needs re-verify` · `PARTIAL` · `FAIL` · `Blocked` · `Owner-UAT` · `N/A`. `Owner-UAT` marks a row only the owner can close, by following the UsageGuide test plan; the verifier cannot reach it from this machine.
 
-     A REQ whose BRD NFR declared a `perf-budget:` carries that line VERBATIM in its
-     Acceptance bullet — split-brd copies it across unchanged. It is machine-read by
-     verify-phase §4c, which grades speed only where such a line exists. Never add one
-     that the BRD did not state, and never paraphrase it: the grammar is
-         perf-budget: <p50|p95|max> <ttfb|load> <= <N>ms [@ concurrency <N>] -->
-
-
-### Page: Dashboard (`/dashboard`)
+## Page: {Screen name} (`/route`)
 
 <a id="d-req-ui-001"></a>
-- **REQ-UI-001** — TrBlazeUI top nav (logo, user menu, theme toggle). *Mockup:* docs/mockups/dashboard.html.
-  - *Acceptance:* page renders; nav fixed-top; theme toggle persists in localStorage; controls do not overlap at desktop + mobile widths (visual gate).
-
-## Functional requirements
+- **REQ-UI-001** — {what the screen shows}. *BRD:* BRD-{N} · *Mockup:* mockups/{screen-slug}.html
+  - *Acceptance:* When {actor} opens {screen}, then {what is visible, with real data, at desktop and mobile widths}.
 
 <a id="d-req-fn-001"></a>
-- **REQ-FN-001** — <trigger / acceptance>.
-
-<!-- Example of a perf-gated NFR row (only where the BRD declared the budget):
-<a id="d-req-nfr-001"></a>
-- **REQ-NFR-001** — Public pages stay responsive under normal load. (BRD-N)
-  - *Acceptance:* pages return 200 and render their data; perf-budget: p95 load <= 2000ms @ concurrency 1
--->
-
-
-## RAG / AI requirements (→ /techierag)
-
-<a id="d-req-rag-001"></a>
-- **REQ-RAG-001** — <trigger / acceptance via TechieRag>.
+- **REQ-FN-001** — {what the user can do}. *BRD:* BRD-{N}
+  - *Acceptance:* When {actor} {does what} on {screen}, then {observable result}.
 
 ## Non-functional
 
 <a id="d-req-nfr-001"></a>
-- **REQ-NFR-001** — <perf / security / accessibility>.
+- **REQ-NFR-001** — {the requirement}. *BRD:* BRD-{N}
+  - *Acceptance:* When {the measurement is taken}, then {the value within its limit}; perf-budget: p95 load <= 2000ms @ concurrency 1

package/.tfcore/templates/v4custom/app-claude-md-tmpl.md

@@ -26,7 +26,7 @@
 | Confirm a **framework** file exists | Glob/Grep for its name — **returns nothing even when it is there** | **Read** the literal path (`.tfcore/…`) — see below |
 | Loop over a list of files | `for f in ...; do ...; done` | Multiple parallel Read/Edit calls in one assistant turn |
 
-**Glob and Grep cannot see the framework tree.** `.tfcore/`, `.claude/`, `.codex/`, `.opencode/` and `.agents/skills/` are hidden dot-directories *and* are gitignored in this repo (deliberately — the deployed framework copies are never committed). Grep is ripgrep-backed: it skips hidden paths AND honours `.gitignore`, so it needs **both** flags — `rg --hidden --no-ignore`, i.e. `rg -uu`. `--hidden` alone is not enough. Glob, `git grep` and `git ls-files` are blind for the same reasons.
+**Glob and Grep cannot see the framework tree.** `.tfcore/`, `.claude/` and `.opencode/` are hidden dot-directories *and* are gitignored in this repo (deliberately — the deployed framework copies are never committed). Grep is ripgrep-backed: it skips hidden paths AND honours `.gitignore`, so it needs **both** flags — `rg --hidden --no-ignore`, i.e. `rg -uu`. `--hidden` alone is not enough. Glob, `git grep` and `git ls-files` are blind for the same reasons.
 
 So **a search returning nothing is not evidence that a framework file is missing.** Confirm framework files by **Read**ing the literal path (every one has exactly one canonical location, and whatever needs it names that path). Never report one as absent without having tried the path first — that false negative gets written into the checklist and the BRD, where the next agent inherits it as fact. If a framework file really is gone, the repo needs `update-framework.sh <repo>` run once on this machine; say that rather than working around it. Full rule: `.tfcore/tasks/_status-update-gate.md` §"The framework tree is INVISIBLE to search".
 

package/.tfcore/templates/v4custom/app-coding-standards-tmpl.md

@@ -0,0 +1,52 @@
+<!-- tf-schema
+doc: coding-standards
+file: docs/{App}-Coding-Standards.md
+header: App, Stack answer set, Date
+section: Standards applied | required
+section: Project rules | required
+section: Enforcement | required
+budget: S 800 1200 | M 800 1200 | L 800 1200
+rule: standards-pointer
+-->
+<!-- Authoring notes (agent only; never visible text).
+     The standards themselves live in the framework and are not copied here:
+       .tfcore/standards/coding-standards-core.md    (every project, technology-neutral)
+       .tfcore/standards/coding-standards-<stack>.md (the stack's answer set, e.g. dotnet)
+     This file says which of those apply and lists only the rules specific to this project.
+     The Project rules table is often empty; a mixed-technology build rule or a per-project naming
+     choice is the kind of thing that belongs here. Fixed budget for every size. -->
+
+# {App} — Coding Standards
+
+| | |
+|---|---|
+| App | {App} |
+| Stack answer set | {name, or "none"} |
+| Date | {YYYY-MM-DD} |
+
+## Standards applied
+
+| File | Applies | Notes |
+|---|---|---|
+| `.tfcore/standards/coding-standards-core.md` | yes | every project |
+| `.tfcore/standards/coding-standards-{stack}.md` | yes | {from the Stack answer set} |
+
+Per-project choices the stack file leaves open:
+
+| Choice | Decision |
+|---|---|
+| {e.g. instance-field prefix} | {…} |
+
+## Project rules
+
+Rules that hold in this project only. Empty is a valid answer.
+
+| Rule | Why | Since |
+|---|---|---|
+| {…} | {…} | {YYYY-MM-DD} |
+
+## Enforcement
+
+- **Editor configuration:** `.editorconfig` at the repository root carries the machine-checkable subset.
+- **Analyzers:** {which, or "none"}.
+- **Verifier checks:** the standards check runs the greps listed in the stack file's Enforcement section, plus: {any project-specific grep, or "none"}.