@codyswann/lisa 2.302.0 → 2.304.0

package/plugins/src/base/skills/lisa-jira-validate-ticket/SKILL.md

@@ -73,6 +73,8 @@ Gates are grouped into **Specification** (spec-only checks, no JIRA lookups) and
 
 Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Categories drive how downstream callers (notably `lisa-notion-prd-intake`) translate failures into product-facing comments; `product_relevant=false` failures indicate internal data-quality problems (broken parent links, missing core fields) that the agent should fix itself rather than ask product to clarify.
 
+Per-type content requirements are defined once in the vendor-neutral `work-item-definition-of-ready` rule (eager + reference); gates S4–S6 and S17 enforce them, and S18 enforces the stateless-pickup property directly.
+
 | Gate | Category | Product-relevant |
 |------|----------|------------------|
 | S1 Required core fields | `structural` | false |
@@ -91,6 +93,8 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S14 Evidence manifest binding (leaf work units) | `acceptance-criteria` | true |
 | S15 Leaf-only build-ready | `structural` | false |
 | S16 Source Requirement traceability | `product-clarity` | true |
+| S17 Improvement measurability | `acceptance-criteria` | true |
+| S18 Stateless-pickup dry-run | `product-clarity` | true |
 | F1 Issue type valid in project | `structural` | false |
 | F2 Epic parent exists and is an Epic | `structural` | false |
 | F3 Linked tickets exist | `structural` | false |
@@ -138,16 +142,26 @@ The `Acceptance Criteria` section must contain at least one criterion in `Given
 
 #### S5 — Bug-specific content
 
-When `issue_type = Bug`, description must additionally include:
-- Reproduction steps
-- Expected vs. actual behavior
-- Environment where reproduced
+When `issue_type = Bug`, description must additionally include the full bug anatomy from the `work-item-definition-of-ready` rule:
+
+- **Agent-executable reproduction** — numbered steps a stateless agent can run mechanically: exact entry point, named account/role (consistent with Sign-in Required when authenticated), concrete data state, exact actions. Human-followable-only prose ("click around until it breaks") FAILs. A linked failing test satisfies this outright and is the preferred form.
+- **Expected vs. actual behavior**, naming or linking the *source* of "expected" (spec, PRD requirement, prior release behavior) — a fix target is a fact, not an opinion.
+- **Environment + version** — where reproduced and the build/commit observed; last-known-good when known (`unknown` must be stated, not omitted).
+- **Reproducibility rate** — always, or intermittent with observed frequency; intermittent invalidates run-once verification.
+- **Occurrence evidence** — at least one link/attachment: error-tracker issue, log excerpt, stack trace, screenshot/recording.
+
+A Bug's terminal state is its reproduction: the same steps (or test) fail before the fix and pass after — capture both as evidence: under the S14 manifest when `runtime_behavior_change = true`, or attached directly to the item for non-runtime Bugs (doc/config fixes), where S14 is N/A.
 
 #### S6 — Spike-specific content
 
 When `issue_type = Spike`, description must include:
-- The question being answered
-- Definition of done (decision doc / prototype / findings deliverable)
+
+- The **question** being answered
+- The **decision** the answer enables, and the options being weighed
+- A **timebox**
+- **Deliverable format and location** — decision doc / prototype / findings page, and where it will live, so the terminal state — a deliverable at that location that actually answers the question, with findings, decision and options — is checkable
+
+Gherkin AC is intentionally N/A for Spikes (S4).
 
 #### S7 — Epic parent declared
 
@@ -191,6 +205,8 @@ Accept either placement — both are valid per `lisa-tracker-source-artifacts`:
 
 Detect by scanning for the phrase `Source Precedence` (case-insensitive) anywhere in the description, AND verifying the four axes (business rules, visual, flow, data) are each named. Missing the phrase OR missing one or more axes: FAIL with a remediation that names the missing axes.
 
+If the spec doesn't set `artifacts_attached`, infer it the same way S9 infers sign-in: scan the description for design/mock/prototype/data-artifact references (design-tool links, "mock", "prototype", spreadsheet or API artifacts). If such artifacts are referenced and no source-precedence guidance exists: FAIL.
+
 #### S13 — Relationship Search documented
 
 The ticket must EITHER have at least one issue link in `links`, OR the description / a comment must contain a `## Relationship Search` block listing the git history queries and JQL queries that were run with their outcomes ("Searched git history for `<keywords>` and JQL for component=`X`; no related work found.").
@@ -269,6 +285,22 @@ R-id with no quote: FAIL with remediation
 `product_relevant: true` — a ticket whose requirement cannot be traced is
 a product-clarity problem: nobody can tell why the work exists.
 
+#### S17 — Improvement measurability
+
+When `issue_type = Improvement`, the description must define the improvement as a measured delta per `work-item-definition-of-ready`:
+
+- **Metric + measurement method** the agent can run (command, query, dashboard export)
+- **Baseline** — the current measured value (a number, not an adjective)
+- **Target** — the numeric value or bound that defines done
+
+Without a baseline and a target an Improvement has no verifiable terminal state and can never be autonomously closed. FAIL names the missing pieces; when no baseline exists yet, the remediation is to file measuring it as the first step. `N/A` for every other type.
+
+#### S18 — Stateless-pickup dry-run
+
+The autonomy gate, run last, on every build-ready leaf (use the S15 classification; `N/A` for containers and non-build-ready items). Simulate a stateless agent reading only this item and the links it can resolve — session knowledge about the codebase does not count, because the next claimant will not have it. List every question that agent would have to ask a human before starting work, before choosing between materially different implementations, or before declaring the work done.
+
+Zero questions → PASS. Any question → FAIL, with each question listed verbatim as its own remediation line — these are exactly the clarifying comments the caller posts to the source. The structure gates are proxies; this gate checks the readiness property itself: `ready` means a stateless agent can drive this item to its terminal state with zero human clarification (see `work-item-definition-of-ready`).
+
 ### Feasibility Gates (require JIRA lookups; skip in dry-run if requested)
 
 #### F1 — Issue type valid in project
@@ -354,6 +386,8 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] S14 Evidence manifest binding — <one-line reason>
 - [PASS|FAIL|N/A] S15 Leaf-only build-ready — <one-line reason>
 - [PASS|FAIL|N/A] S16 Source Requirement traceability — <one-line reason>
+- [PASS|FAIL|N/A] S17 Improvement measurability — <one-line reason>
+- [PASS|FAIL|N/A] S18 Stateless-pickup dry-run — <one-line reason>
 
 ### Feasibility Gates  (omit this section when --spec-only)
 - [PASS|FAIL|N/A] F1 Issue type valid in project — <one-line reason>
@@ -379,7 +413,7 @@ The verdict is `PASS` if and only if every applicable gate is `PASS`. Any `FAIL`
 
 ### Failure-detail fields
 
-- **gate**: the gate ID (`S1`–`S15`, `F1`–`F5`).
+- **gate**: the gate ID (`S1`–`S18`, `F1`–`F5`).
 - **category**: the gate's fixed category from the table above. Callers use this to label or filter comments — `product-clarity`, `acceptance-criteria`, `design-ux`, `scope`, `dependency`, `data`, `technical`, or `structural`.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem (e.g., the agent built a malformed spec, an issue type is invalid in the project) and the caller should fix it without bothering the product team. `true` means the PRD needs product input to resolve.
 - **what**: plain-language description of the issue. No gate IDs, no JIRA jargon, no engineering shorthand. A product owner reading this on a Notion comment should understand what is unclear and why.

package/plugins/src/base/skills/lisa-linear-to-tracker/SKILL.md

@@ -208,6 +208,30 @@ The register feeds three consumers: the `## Source Requirement` section on
 every created ticket (Phases 3–5), the dry-run report (above), and the
 requirement tokens in the PRD back-link (Phase 7).
 
+### Phase 1.45: Requirement Quality Gates (prd-definition-of-ready)
+
+Validate every Phase 1.4 register entry against the `prd-definition-of-ready` rule before
+planning proceeds. Per atom:
+
+- **Singular** — one behavior per entry. An entry welding multiple shall/when clauses together is
+  split in the register (R4 → R4a/R4b) when the split is mechanical and meaning-preserving; when
+  the split would change meaning, it is a product question, not a repair.
+- **Unambiguous** — FAIL on the vagueness lexicon ("as appropriate", "user-friendly", "fast",
+  "handle gracefully", "etc.", "and/or", unbounded "optimize"/"support"): phrasing no test can
+  check. The full lexicon lives in the rule's reference body.
+- **Verifiable** — a fit criterion (the measurable test of satisfaction) is present or
+  mechanically derivable from the text; a requirement no test could check is not admitted as a
+  requirement.
+- **Pattern shape (SHOULD)** — an EARS pattern (ubiquitous / When / While / If-then / Where) or an
+  equivalent single-behavior sentence; conforming shapes decompose into Gherkin mechanically.
+
+Failures here are **requirement-level product clarifications**, not internal errors: report each in
+the dry-run report as a `product-clarity` item quoting the atom verbatim, naming the defect, and
+offering 1–3 candidate rewrites (an EARS-shaped rewrite is the default recommendation). In intake
+flows these route to the PRD's `blocked` role with comments, exactly like ticket-validator
+failures. Mechanical splits and derived fit criteria are repaired in-register and recorded in the
+report — never silently.
+
 ### Phase 1.5: Extract Source Artifacts
 
 PRDs typically reference external design, UX, and data artifacts (Figma files, Lovable prototypes, Loom walkthroughs, screenshots, example payloads, peer Linear or Confluence pages). These MUST be preserved onto the resulting tickets — otherwise developers picking up a ticket lose the source of truth. This is the failure mode this step exists to prevent.

package/plugins/src/base/skills/lisa-linear-validate-issue/SKILL.md

@@ -74,6 +74,8 @@ Gates are grouped into **Specification** (spec-only checks, no Linear lookups) a
 
 Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Categories drive how downstream callers (notably `lisa-linear-prd-intake`) translate failures into product-facing comments; `product_relevant=false` failures indicate internal data-quality problems the agent should fix itself rather than ask product to clarify.
 
+Per-type content requirements are defined once in the vendor-neutral `work-item-definition-of-ready` rule (eager + reference); gates S4–S6 and S17 enforce them, and S18 enforces the stateless-pickup property directly.
+
 | Gate | Category | Product-relevant |
 |------|----------|------------------|
 | S1 Required core fields | `structural` | false |
@@ -92,6 +94,8 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S14 Evidence manifest binding (leaf work units) | `acceptance-criteria` | true |
 | S15 Leaf-only build-ready | `structural` | false |
 | S16 Source Requirement traceability | `product-clarity` | true |
+| S17 Improvement measurability | `acceptance-criteria` | true |
+| S18 Stateless-pickup dry-run | `product-clarity` | true |
 | F1 Issue type valid in team | `structural` | false |
 | F2 Project parent exists and is in same team | `structural` | false |
 | F3 Linked items exist | `structural` | false |
@@ -139,16 +143,26 @@ The `Acceptance Criteria` section must contain at least one criterion in `Given
 
 #### S5 — Bug-specific content
 
-When `issue_type = Bug`, description must additionally include:
-- Reproduction steps
-- Expected vs. actual behavior
-- Environment where reproduced
+When `issue_type = Bug`, description must additionally include the full bug anatomy from the `work-item-definition-of-ready` rule:
+
+- **Agent-executable reproduction** — numbered steps a stateless agent can run mechanically: exact entry point, named account/role (consistent with Sign-in Required when authenticated), concrete data state, exact actions. Human-followable-only prose ("click around until it breaks") FAILs. A linked failing test satisfies this outright and is the preferred form.
+- **Expected vs. actual behavior**, naming or linking the *source* of "expected" (spec, PRD requirement, prior release behavior) — a fix target is a fact, not an opinion.
+- **Environment + version** — where reproduced and the build/commit observed; last-known-good when known (`unknown` must be stated, not omitted).
+- **Reproducibility rate** — always, or intermittent with observed frequency; intermittent invalidates run-once verification.
+- **Occurrence evidence** — at least one link/attachment: error-tracker issue, log excerpt, stack trace, screenshot/recording.
+
+A Bug's terminal state is its reproduction: the same steps (or test) fail before the fix and pass after — capture both as evidence: under the S14 manifest when `runtime_behavior_change = true`, or attached directly to the item for non-runtime Bugs (doc/config fixes), where S14 is N/A.
 
 #### S6 — Spike-specific content
 
 When `issue_type = Spike`, description must include:
-- The question being answered
-- Definition of done (decision doc / prototype / findings deliverable)
+
+- The **question** being answered
+- The **decision** the answer enables, and the options being weighed
+- A **timebox**
+- **Deliverable format and location** — decision doc / prototype / findings page, and where it will live, so the terminal state — a deliverable at that location that actually answers the question, with findings, decision and options — is checkable
+
+Gherkin AC is intentionally N/A for Spikes (S4).
 
 #### S7 — Project parent declared
 
@@ -194,6 +208,8 @@ Accept either placement:
 
 Detect by scanning for the phrase `Source Precedence` (case-insensitive) anywhere in the description AND verifying the four axes are each named. Missing the phrase OR any axis: FAIL with remediation naming the missing axes.
 
+If the spec doesn't set `artifacts_attached`, infer it the same way S9 infers sign-in: scan the description for design/mock/prototype/data-artifact references (design-tool links, "mock", "prototype", spreadsheet or API artifacts). If such artifacts are referenced and no source-precedence guidance exists: FAIL.
+
 #### S13 — Relationship Search documented
 
 The item must EITHER have at least one entry in `relations`, OR the description / a comment must contain a `## Relationship Search` block listing the git history queries and Linear MCP queries that were run with their outcomes.
@@ -271,6 +287,22 @@ R-id with no quote: FAIL with remediation
 `product_relevant: true` — a issue whose requirement cannot be traced is
 a product-clarity problem: nobody can tell why the work exists.
 
+#### S17 — Improvement measurability
+
+When `issue_type = Improvement`, the description must define the improvement as a measured delta per `work-item-definition-of-ready`:
+
+- **Metric + measurement method** the agent can run (command, query, dashboard export)
+- **Baseline** — the current measured value (a number, not an adjective)
+- **Target** — the numeric value or bound that defines done
+
+Without a baseline and a target an Improvement has no verifiable terminal state and can never be autonomously closed. FAIL names the missing pieces; when no baseline exists yet, the remediation is to file measuring it as the first step. `N/A` for every other type.
+
+#### S18 — Stateless-pickup dry-run
+
+The autonomy gate, run last, on every build-ready leaf (use the S15 classification; `N/A` for containers and non-build-ready items). Simulate a stateless agent reading only this item and the links it can resolve — session knowledge about the codebase does not count, because the next claimant will not have it. List every question that agent would have to ask a human before starting work, before choosing between materially different implementations, or before declaring the work done.
+
+Zero questions → PASS. Any question → FAIL, with each question listed verbatim as its own remediation line — these are exactly the clarifying comments the caller posts to the source. The structure gates are proxies; this gate checks the readiness property itself: `ready` means a stateless agent can drive this item to its terminal state with zero human clarification (see `work-item-definition-of-ready`).
+
 ### Feasibility Gates (require Linear lookups; skip in dry-run if requested)
 
 #### F1 — Issue type valid in team
@@ -360,6 +392,8 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] S14 Evidence manifest binding — <one-line reason>
 - [PASS|FAIL|N/A] S15 Leaf-only build-ready — <one-line reason>
 - [PASS|FAIL|N/A] S16 Source Requirement traceability — <one-line reason>
+- [PASS|FAIL|N/A] S17 Improvement measurability — <one-line reason>
+- [PASS|FAIL|N/A] S18 Stateless-pickup dry-run — <one-line reason>
 
 ### Feasibility Gates  (omit when --spec-only)
 - [PASS|FAIL|N/A] F1 Issue type valid in team — <one-line reason>

package/plugins/src/base/skills/lisa-linear-write-prd/SKILL.md

@@ -86,6 +86,8 @@ outcome: created | reused
 
 ## Rules
 
+- The PRD body's requirements MUST conform to `prd-definition-of-ready`: identified atoms (`R1`, `R2`, …), one behavior each in an EARS-pattern shape, each with a measurable fit criterion, plus the non-functional checklist. This governs factory-authored bodies; human-authored PRDs are validated at intake instead (`*-to-tracker` Phase 1.45).
+
 - Exactly one PRD lifecycle project-label at all times.
 - Match dedupe by marker, never by project name.
 - Preserve an existing canonical `## Lisa Usage` section on update; never append a second usage

package/plugins/src/base/skills/lisa-notion-to-tracker/SKILL.md

@@ -190,6 +190,30 @@ The register feeds three consumers: the `## Source Requirement` section on
 every created ticket (Phases 3–5), the dry-run report (above), and the
 requirement tokens in the PRD back-link (Phase 7).
 
+### Phase 1.45: Requirement Quality Gates (prd-definition-of-ready)
+
+Validate every Phase 1.4 register entry against the `prd-definition-of-ready` rule before
+planning proceeds. Per atom:
+
+- **Singular** — one behavior per entry. An entry welding multiple shall/when clauses together is
+  split in the register (R4 → R4a/R4b) when the split is mechanical and meaning-preserving; when
+  the split would change meaning, it is a product question, not a repair.
+- **Unambiguous** — FAIL on the vagueness lexicon ("as appropriate", "user-friendly", "fast",
+  "handle gracefully", "etc.", "and/or", unbounded "optimize"/"support"): phrasing no test can
+  check. The full lexicon lives in the rule's reference body.
+- **Verifiable** — a fit criterion (the measurable test of satisfaction) is present or
+  mechanically derivable from the text; a requirement no test could check is not admitted as a
+  requirement.
+- **Pattern shape (SHOULD)** — an EARS pattern (ubiquitous / When / While / If-then / Where) or an
+  equivalent single-behavior sentence; conforming shapes decompose into Gherkin mechanically.
+
+Failures here are **requirement-level product clarifications**, not internal errors: report each in
+the dry-run report as a `product-clarity` item quoting the atom verbatim, naming the defect, and
+offering 1–3 candidate rewrites (an EARS-shaped rewrite is the default recommendation). In intake
+flows these route to the PRD's `blocked` role with comments, exactly like ticket-validator
+failures. Mechanical splits and derived fit criteria are repaired in-register and recorded in the
+report — never silently.
+
 ### Phase 1.5: Extract Source Artifacts
 
 PRDs typically reference external design, UX, and data artifacts (Figma files, Lovable prototypes, Loom walkthroughs, screenshots, example payloads, Confluence pages). These MUST be preserved onto the resulting tickets — otherwise developers picking up a ticket lose the source of truth. This is the failure mode this step exists to prevent.

package/plugins/src/base/skills/lisa-notion-write-prd/SKILL.md

@@ -100,6 +100,8 @@ outcome: created | reused
 
 ## Rules
 
+- The PRD body's requirements MUST conform to `prd-definition-of-ready`: identified atoms (`R1`, `R2`, …), one behavior each in an EARS-pattern shape, each with a measurable fit criterion, plus the non-functional checklist. This governs factory-authored bodies; human-authored PRDs are validated at intake instead (`*-to-tracker` Phase 1.45).
+
 - All access via `lisa-notion-access`; never touch the Notion API/MCP directly.
 - Match dedupe by marker, never by title.
 - Preserve an existing canonical `## Lisa Usage` section on update; never append a second usage

package/plugins/src/base/skills/lisa-research/SKILL.md

@@ -56,7 +56,9 @@ A PRD **created in the configured PRD source** (per the intent-routing rule's Re
 definition) structured as: problem statement, high-level solution description, links (if needed),
 user stories (each with its own functional/non-functional requirements and, only for stories with
 new UI/visual work, a design-file pointer), overall acceptance criteria, open questions, and the
-"Recommended Tooling for Plan Phase" section. The final
+"Recommended Tooling for Plan Phase" section. Requirements MUST conform to the
+`prd-definition-of-ready` rule: identified atoms (`R1`, `R2`, …), one behavior each in an
+EARS-pattern shape, each with a measurable fit criterion, plus the non-functional checklist. The final
 flow step invokes `lisa-prd-source-write`, which creates the PRD in the configured `source` (Notion
 page in the PRD database, Confluence page under the lifecycle parent, GitHub issue, or Linear
 project) in the `draft` role by default or `ready` when `prd_ready=true`. **The PRD lives in the

package/ui/index.html

@@ -5097,14 +5097,14 @@
       /* ---------------------------------- Readiness (intake) ---------------------------------- */
       DATA.sections.readiness = {
         title: "Readiness",
-        desc: "The onboarding questionnaire — Vanta, but for agent-run software. Answer what you use for each thing an autonomous factory depends on, and the meter shows how ready you are. Every question here has a detailed home elsewhere in the console; this is the flat version you fill out first. Nothing is required all at once — an unanswered question is a known gap, not a failure.",
+        desc: "The onboarding questionnaire — and the working Annex B self-assessment instrument of TASC (spec/tasc-0.1-draft.md). Answer what you use for each thing an autonomous factory depends on, and the meter shows how ready you are; each group cites the TASC criteria it evidences. Every question has a detailed home elsewhere in the console; this is the flat version you fill out first. Nothing is required all at once — an unanswered question is a known gap, not a failure.",
         src: "intake · maps onto .lisa.config.json",
         blocks: [
           {
             type: "intake",
             groups: [
               {
-                label: "The bottom line",
+                label: "The bottom line (AC7.4)",
                 note: "The one number the rest of this questionnaire exists to predict.",
                 items: [
                   {
@@ -5121,7 +5121,7 @@
                 ],
               },
               {
-                label: "Credentials & access",
+                label: "Credentials & access (AC6)",
                 items: [
                   {
                     q: "Where do your agents' secrets live?",
@@ -5175,7 +5175,7 @@
                 ],
               },
               {
-                label: "Where agents run",
+                label: "Where agents run (AC6 · AC9.5)",
                 items: [
                   {
                     q: "What sandbox do unattended agents run in?",
@@ -5227,7 +5227,7 @@
                 ],
               },
               {
-                label: "The agent's program",
+                label: "The agent's program (AC8.2–8.3 · AC4.5)",
                 note: "Prompts, skills and models are the factory's own source code and runtime. This group asks whether that layer is under change control — or improvised per run.",
                 items: [
                   {
@@ -5270,10 +5270,22 @@
                       "None",
                     ],
                   },
+                  {
+                    q: "When an agent makes a mistake, what stops the next agent repeating it?",
+                    help: "TASC AC4.5 — the self-learning loop. Mistakes and drift are captured with provenance, pass a skeptical gate, and get promoted upstream into lint rules, hooks, gates and skills. A lesson that stays prose is one the next agent never reads; recurrence of a captured mistake means the loop failed.",
+                    kind: "select",
+                    value: "Captured, judged, promoted to enforcement",
+                    options: [
+                      "Captured, judged, promoted to enforcement",
+                      "Captured in docs / notes",
+                      "Fixed locally, lesson lost",
+                      "Nothing",
+                    ],
+                  },
                 ],
               },
               {
-                label: "Work intake",
+                label: "Work intake (AC8.4 · AC8.6)",
                 items: [
                   {
                     q: "Where do product requirements (PRDs) live?",
@@ -5328,10 +5340,33 @@
                       "Built as written",
                     ],
                   },
+                  {
+                    q: "Is there a definition of ready, enforced per work-item type?",
+                    help: "TASC AC8.6. A bug needs machine-executable reproduction; an improvement needs a measured baseline and a numeric target; a spike needs its question, timebox and deliverable location. One generic checklist cannot guarantee a stateless agent finishes without asking a human.",
+                    kind: "select",
+                    value: "Type-keyed gates, machine-validated",
+                    options: [
+                      "Type-keyed gates, machine-validated",
+                      "One generic checklist",
+                      "Reviewer judgment",
+                      "None",
+                    ],
+                  },
+                  {
+                    q: "Are requirements written as testable atoms?",
+                    help: "TASC AC8.4. Identified requirement atoms — one behavior each, patterned syntax (EARS: When X, the system shall Y), each with a measurable fit criterion — are what let a planner decompose mechanically and a verifier check conformance. A paragraph welding three requirements together degrades tracing, coverage and verification all at once.",
+                    kind: "select",
+                    value: "Identified atoms — patterned + fit criteria",
+                    options: [
+                      "Identified atoms — patterned + fit criteria",
+                      "Structured prose",
+                      "Free-form documents",
+                    ],
+                  },
                 ],
               },
               {
-                label: "Correctness gates",
+                label: "Correctness gates (SI1–SI3 · AC5.4)",
                 items: [
                   {
                     q: "Is unit behaviour proven on every change?",
@@ -5358,7 +5393,7 @@
                   },
                   {
                     q: "Minimum unit-test coverage you enforce?",
-                    help: "Below this the build fails. Thresholds should only ratchet up.",
+                    help: "Below this the build fails. TASC SI2: the floor must be nonzero and disclosed, and it only ratchets up — zero is not a floor.",
                     kind: "number",
                     value: 74,
                     unit: "%",
@@ -5399,7 +5434,7 @@
                 ],
               },
               {
-                label: "Security gates",
+                label: "Security gates (AC5 · AC9)",
                 items: [
                   {
                     q: "What blocks a committed secret?",
@@ -5475,9 +5510,19 @@
                 ],
               },
               {
-                label: "Agent attack surface",
+                label: "Agent attack surface (AC3)",
                 note: "The group above secures the code; this one secures the agent. Inbound, the risk is untrusted content steering it; outbound, exfiltration — which is governed by the egress lock and credential gateway you answered earlier.",
                 items: [
+                  {
+                    q: "Is there a written threat model for your agents?",
+                    help: "TASC AC3.1. The rows below are mitigations; this asks whether the model itself exists as a document — revisited when the system changes — so the mitigations are answers to named threats rather than folklore.",
+                    kind: "select",
+                    options: [
+                      "Yes — revisited on system change",
+                      "Written once, going stale",
+                      "No",
+                    ],
+                  },
                   {
                     q: "What stops fetched content from becoming instructions?",
                     help: "Prompt injection: a web page, README, or issue comment the agent reads is untrusted input that may try to steer it. Mitigation means labeling it as data and gating risky tools while it is in context.",
@@ -5573,7 +5618,7 @@
                 ],
               },
               {
-                label: "Code health",
+                label: "Code health (SI7)",
                 note: "The bar for this whole group: authorless code. A reviewer with the author hidden should not be able to tell who — or what — wrote a change. Anything that gives the author away is an uncodified opinion, and each row below is one class of opinion made enforceable.",
                 items: [
                   {
@@ -5656,7 +5701,7 @@
                 ],
               },
               {
-                label: "Design & UI",
+                label: "Design & UI (UX)",
                 note: "The determinism story for anything with a screen — a design system is the linter for UI. Without one an agent improvises every screen; with one it assembles from known parts. A backend or CLI answers “no UI” to each, which counts as answered.",
                 items: [
                   {
@@ -5708,7 +5753,7 @@
                 ],
               },
               {
-                label: "Review & merge",
+                label: "Review & merge (AC8.1 · AC5)",
                 items: [
                   {
                     q: "What reviews every diff before merge?",
@@ -5745,10 +5790,21 @@
                       "No — advisory only",
                     ],
                   },
+                  {
+                    q: "When did a gate last actually block a change?",
+                    help: "TASC AC5.5, and the exercised-evidence principle in one question: a gate that has never fired is indistinguishable from one that was never wired up. Being able to point at a recent block is the strongest evidence a control exists.",
+                    kind: "select",
+                    value: "Recently — we can point to it",
+                    options: [
+                      "Recently — we can point to it",
+                      "It has blocked before",
+                      "Never — or we can't tell",
+                    ],
+                  },
                 ],
               },
               {
-                label: "Ship & rollback",
+                label: "Ship & rollback (AC8.5 · AC7.2)",
                 note: "Change management — the human-shaped hole. In a human SDLC a person approved the deploy and reverted the bad one; every row here is that person's named replacement.",
                 items: [
                   {
@@ -5812,7 +5868,7 @@
                 ],
               },
               {
-                label: "Verify & acceptance",
+                label: "Verify & acceptance (SI5–SI6)",
                 note: "Processing integrity: green CI proves the tests passed, not that the product works. Something has to use it.",
                 items: [
                   {
@@ -5844,7 +5900,7 @@
                 ],
               },
               {
-                label: "Observe",
+                label: "Observe (AC4)",
                 items: [
                   {
                     q: "What captures production errors?",
@@ -5874,6 +5930,16 @@
                       "None",
                     ],
                   },
+                  {
+                    q: "Does a production threshold crossing become a work item automatically?",
+                    help: "TASC AC4.3 — the routing half of observability. Sensing without filing means a human still stands between the signal and the fix. Findings enter through the same validated intake as any other work; no privileged path.",
+                    kind: "select",
+                    options: [
+                      "Yes — filed through validated intake",
+                      "Alerts a human, who files",
+                      "Dashboards only",
+                    ],
+                  },
                   {
                     q: "What tells you what users actually do?",
                     help: "Product analytics is the richest Research input there is — it routes usage patterns back to the Research gate as PRD material.",
@@ -5890,7 +5956,7 @@
                 ],
               },
               {
-                label: "Operate & recover",
+                label: "Operate & recover (AC7 · AC2)",
                 note: "Availability — the who-notices-at-3am group. Factories fail loudly; sensors and schedulers fail silently, and silence is ambiguous.",
                 items: [
                   {
@@ -5945,6 +6011,16 @@
                       "None",
                     ],
                   },
+                  {
+                    q: "Could a non-technical operator understand what the system tells them?",
+                    help: "TASC AC2.1. Blocked reasons, clarifying questions, verdicts and escalations are read by whoever stands at the gate — often not an engineer. A boundary message that reads like a stack trace is a control that fails its audience.",
+                    kind: "select",
+                    options: [
+                      "Yes — plain language is the contract at every boundary",
+                      "Mixed",
+                      "It reads like stack traces",
+                    ],
+                  },
                   {
                     q: "Does every scheduled loop end each run in a named outcome?",
                     help: "A runbook contract: each run terminates in exactly one of a fixed outcome set (nothing needed, work proposed, change proved, approval requested, recovery required, policy obsolete) with an operator-readable summary. A run that just stops is illegible — and illegible runs are how dead loops hide.",
@@ -5959,7 +6035,7 @@
                 ],
               },
               {
-                label: "Governance & accountability",
+                label: "Governance & accountability (AC1 · AC9.1 · DP)",
                 note: "The audit-trail cluster: everything a human used to vouch for by being in the room.",
                 items: [
                   {