acstack 0.49.1 → 0.50.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "acstack",
   "description": "Agentic coding stack where planning grows only as far as needed: a map of decisions, tasks, checks, and handoffs behind a pluggable tracker.",
-  "version": "0.49.1",
+  "version": "0.50.0",
   "author": {
     "name": "ac8318740"
   },

package/README.md

@@ -1,6 +1,6 @@
 # ACStack
 
-ACStack is an agentic coding stack. It makes coding agents plan before they code, write tests before implementation, and keep docs matching the code.
+ACStack is an agentic coding stack. It helps coding agents clarify requirements, test meaningful behavior, and keep docs matching the code.
 
 - **ACStack aims to solve two common failure modes coding agents introduce**
     - The agent starts building before the requirements are clear
@@ -9,9 +9,9 @@ ACStack is an agentic coding stack. It makes coding agents plan before they code
     - Claude Code installs it as a plugin
     - pi installs it as an npm package
 - **ACStack introduces structure around how your agent works**
-    - Every change goes through a test-writer, an implementer, and a checker
+    - Verification fits the change under a shared policy in `orchestrator/AGENTS.md`
     - Every commit updates your specs from the diff
-- **Downside: this structure may make your agent take longer on small tweaks than necessary**
+- Straightforward work can stay with one agent, including investigation, tests, implementation, and verification
 
 ```mermaid
 flowchart TD
@@ -276,19 +276,19 @@ What an effort leaves behind is what matters: updated specs, decision notes, and
 
 ## 6. Every agent
 
-*Four agents run in order. The one rule that matters: the test-writer never sees the implementation.*
+*Use agents when independent interpretation, review, or parallel scopes improve confidence.*
 
 | Agent | Role |
-|-------|------|
-| `test-writer` | Writes tests from requirements only, before the code under strict TDD and after it under relaxed |
-| `task-executor` | TDD phase 2, making tests pass, and it cannot modify tests |
-| `task-checker` | TDD phase 3, verifying everything: mock skepticism, test baseline, regressions, TDD isolation audit |
-| `frontend-verifier` | TDD phase 4, real browser verification via agent-browser CLI, when `project.yaml` configures a frontend |
+| --- | --- |
+| `test-writer` | Optional independent tests from requirements and interfaces |
+| `task-executor` | Implements source and tests unless tests have a separate owner |
+| `task-checker` | Independent review of behavior, coverage, regressions, and integration |
+| `frontend-verifier` | Configured real-browser verification on final frontend code |
 
-- The agent session you talk to coordinates
-    - It hands every piece of research and code to these agents
-- A fail from the task-checker sends the work back to the task-executor with the reason
-- The frontend-verifier runs under three conditions: a configured frontend, changed frontend files, and verification switched on
+- `orchestrator/AGENTS.md` owns the shared Implementation discipline
+- Require independent review for security boundaries, money, irreversible data changes, or unresolved correctness or impact uncertainty
+- Separate test ownership stays separate when chosen
+- Configured frontend gates still apply without a delegated checker
 
 ## 7. Output style
 
@@ -338,28 +338,20 @@ The style also ships a per-turn reminder:
 
 ## 9. Design principles
 
-*Five rules explain why every default is what it is.*
-
-- **Strict TDD holds because of the order the agents run in** – relaxed TDD holds only because the instructions say so
-    - Either way the task-executor cannot edit a test file
-    - Under strict TDD the test-writer runs first
-    - There is no implementation for it to copy
-    - Under relaxed TDD it runs second
-    - Only its instructions stop it reading the code it is testing
-    - The two are not equally safe
-    - That is why strict is the default
-- **Your docs never drift from the code** – `/acstack:commit` reads the diff and updates the specs under `acstack/specs/` in the same commit
-    - Any agent that spots a spec contradicting the code fixes the spec there and then
-    - A spec describes what the code does today
-    - It never describes what someone plans to build
-- **Build no more process than the job needs** – a to-do graph appears only when one conversation cannot hold the questions
-    - A typo fix gets no machinery
-    - A month-long feature gets a map
-    - You type the same command either way
-    - ACStack works out which it is
-- **Planning gets more effort than coding** – three agents read the relevant code before anyone writes a line
-    - Mock audits, regression suites and integration checks follow the implementation
-- **Strict defaults, easy to relax** – run `acstack config set` to change how strict the TDD is, how much the agent does itself, or how it asks you questions
+*Meaningful evidence matters more than a fixed agent sequence.*
+
+- Prefer practical tests-first work to expose mistakes before implementation
+- Require tests for meaningful changed behavior when existing coverage cannot catch mistakes
+- Reuse adequate coverage for refactors and skip new tests for nonbehavioral edits
+- Explain impractical testing and disclose missing regression protection
+- Keep docs current through commit-time spec sync
+- Build no more planning structure than the unanswered questions need
+- Preserve explicit requests for stronger process
+- The deprecated `workflow.tdd.strict` and `workflow.tdd.orchestrator_strict` booleans no longer control sequencing or delegation, including explicit `true`
+    - Neither key has an effective default
+    - ACStack removes the former strict guarantee
+    - ACStack does not automatically rewrite existing configuration
+    - New setup does not offer or generate these keys
 
 ## 10. Licence and credits
 

package/agents/codex/frontend-verifier.toml

@@ -2,12 +2,15 @@
 # Do not edit. Change the markdown and re-run the generator.
 
 name = "frontend-verifier"
-description = "Behavioral UI verification agent. Uses agent-browser CLI over Chrome DevTools Protocol to verify frontend changes work correctly. Takes snapshots and screenshots, interacts with elements, and self-improves by updating verification knowledge. Final gate in the TDD pipeline."
+description = "Behavioral UI verification agent. Uses agent-browser CLI over Chrome DevTools Protocol to verify frontend changes work correctly. Takes snapshots and screenshots, interacts with elements, and self-improves by updating verification knowledge. Runs on final frontend code after required static and design gates pass."
 
 developer_instructions = """
-# Frontend Verifier (TDD Phase 4)
+# Frontend verifier
 
-You verify that frontend changes actually work in a real browser. You are the final gate – after test-writer, task-executor, and task-checker have all passed.
+Verify frontend changes in a real browser after required static checks and any design pass have cleared on the final code.
+
+Follow `orchestrator/AGENTS.md` for the shared verification policy; no fixed agent sequence is a prerequisite.
+Confirm required gate evidence with the verification owner before starting browser work.
 
 **Your sole job**: Connect to a browser. Test the behavior that changed. Report PASS or FAIL with screenshot evidence.
 
@@ -346,7 +349,7 @@ Do NOT kill the browser if you connected to an existing one. In `remote` mode th
 ## What you do NOT do
 
 - You do NOT fix source code bugs – report them for the executor to fix.
-- You do NOT run unit tests – that's the task-checker's job.
-- You do NOT check TypeScript compilation – that's the task-checker's job.
+- You do NOT run unit tests – the verification owner completes those checks first.
+- You do NOT check TypeScript compilation – the verification owner completes that check first.
 - You ONLY verify behavior in a real browser with real screenshots.
 """

package/agents/codex/task-checker.toml

@@ -2,14 +2,17 @@
 # Do not edit. Change the markdown and re-run the generator.
 
 name = "task-checker"
-description = "Verify task implementations are complete, working, and accessible. Binary PASS/FAIL gate with mock skepticism, regression checking, TDD isolation audit, and static frontend checks; browser verification belongs to frontend-verifier."
+description = "Independent verification of behavior, coverage adequacy, regressions, integration, and assigned test ownership. Reports evidence and blockers; browser verification belongs to frontend-verifier."
 
 developer_instructions = """
-# Task checker (TDD phase 3)
+# Task checker
 
 You verify that implemented tasks actually work and are accessible to users. You are the quality gate between 'review' and 'done'.
 
-**Your job**: Confirm the feature is COMPLETE and REACHABLE, not perfect.
+**Your job**: Verify requirements, realistic failure coverage, and integration under the shared Implementation discipline in `orchestrator/AGENTS.md`.
+
+You run when delegated for useful independent verification or when the shared policy requires independent review.
+A fixed agent sequence is not a prerequisite.
 
 ## Project configuration
 
@@ -20,8 +23,7 @@ Read `acstack/project.yaml` for project-specific settings:
 - `commands.build` – build verification
 - `commands.lint` – linting
 - `commands.typecheck` – type checking
-- `directories.tests` – test directory (for TDD isolation check)
-- `workflow.tdd.strict` – `true` by default; `false` means the test-writer ran after the executor, which changes sections 4 and 4.8
+- `directories.tests` – test directory (for assigned ownership checks)
 - `venv.activate` – prefix for commands if set
 - `frontend` – if present, the checker runs the frontend build, lint, and unit tests when frontend files changed (section 5.5)
 - `test_markers.exclude` – markers to exclude from test runs
@@ -50,26 +52,12 @@ Run the build, lint and typecheck commands from project.yaml. Allow no errors.
 - Run the test command from project.yaml
 - All tests must pass
 
-**What `workflow.tdd.strict` changes here**
-
-Read the key in `acstack/project.yaml`. It names the order the first two phases
-ran in.
-
-Under `true` the test-writer ran first, so the task's new tests failed before
-the executor and pass now. Under `false` the executor ran first, so nothing can
-show those tests failing without the implementation.
-
-Under `false` hold three things instead. The new tests exist and pass, the full
-suite passes, and the test count did not drop.
-
-Say in your report that the failing-first evidence is absent, because relaxed
-TDD cannot produce it. The mutation spot-check in section 4.7 is what stands in
-its place.
-
-Under `false` the test-writer read the requirements and wrote its tests against
-a working tree that already held the implementation. That is weaker than the
-strict order, where no implementation exists to read. Treat those tests with
-more suspicion in the mock audit, not less.
+- Assess coverage against changed behavior and requirements under the shared policy
+- Adequate existing coverage can protect refactors without new tests
+- Nonbehavioral changes need no fresh test
+- Explain impractical automated testing, the nearest executable check, and missing regression protection
+- Review available failing-first evidence and any explained departure from tests-first work
+- Test counts alone do not prove adequacy
 
 **Mock skepticism**
 
@@ -94,7 +82,8 @@ If ANY pre-existing test fails -> FAIL immediately.
 
 If `project.yaml` configures `commands.test_collect`, compare the current test count against `.test-baseline`:
 
-If CURRENT < BASELINE -> FAIL. The executor deleted tests to fake a pass rate.
+If CURRENT < BASELINE, investigate the removed coverage and report any unmet project baseline requirement.
+A count alone neither proves adequacy nor establishes who removed a test.
 
 ### 4.7 Systematic mock audit
 
@@ -113,43 +102,18 @@ For each new/modified test file:
 
     If yes -> FAIL. The test observes no behaviour. Typical causes are a weak assertion (`toBeDefined`, `is not None`), a bare `toHaveBeenCalled`, a restated constant, or an expected value computed by the code under test.
 
-4. **Mutation spot-check**: Pick one or two implemented functions. Add an early return to each. Run the tests.
-
-    If tests still pass -> FAIL. Revert the change after the check.
-
-### 4.8 TDD isolation audit
-
-This audit asks one question, and asks it under both settings. Did the
-task-executor write in the test directory?
-
-The ban is absolute. Only the test-writer writes tests, whichever order
-the two phases ran in.
-
-List what changed in the test directory:
-
-```bash
-git diff --name-only -- <test_directory>/
-```
-
-Two kinds of change are not executor edits. The test-writer owns every test
-file it wrote. The format step owns a test file it rewrote, which carries
-formatting only.
+4. **Failure sensitivity**: Explain which plausible wrong behavior each important assertion detects
 
-Read the diff before you fail the audit.
+    A temporary mutation experiment is optional, never a required source edit.
+    Prefer read-only reasoning or an isolated disposable copy when useful.
 
-**Under `true`** the test-writer ran first, so its files were already in place
-when the executor started. Any further change to a test file is an executor
-edit -> FAIL.
+### 4.8 Test ownership audit
 
-**Under `false`** the executor ran first and the test-writer ran after it. The
-test directory changes for that reason, so the file list alone names no author.
-
-Audit the executor's own report of the files it changed. If that report names a
-file under the test directory -> FAIL.
-
-Relaxed TDD means nobody wrote the tests first. It never means the work goes
-unverified, and it drops no phase. Report which order the phases ran in, so
-the reader of your report knows which gate applied.
+- Determine whether the task assigned a separate test owner
+- When assigned, verify the implementer did not edit or weaken that owner's tests
+- Otherwise, the same implementer may edit source and tests
+- Review assertion quality regardless of authorship or test timing
+- Report requirements that remain unprotected
 
 ### 5. Integration wired (CRITICAL)
 
@@ -178,123 +142,25 @@ This is where most failures hide. Verify the complete chain:
 - The state exists, but nothing displays it
 - The button exists, but the handler is empty or missing
 
-### 5.5 Frontend files check
-
-**Note:** The **frontend-verifier agent** (Phase 4) handles full browser verification. The task-checker only checks that the frontend code compiles and passes static analysis.
-
-**The changed frontend file list**
-
-Section 5.5 runs only when `acstack/project.yaml` configures `frontend`.
-`frontend.directory` names the directory. It defaults to `frontend/` when the
-key states nothing.
-
-Check the config before you derive the file list. The config names no frontend
-when the key states nothing and the repository has no `frontend/` directory.
-
-When the config names no frontend, warn in one line that `frontend.directory`
-is missing. Skip section 5.5.
-
-Derive the file list once. Every check below reads the file list.
-
-```bash
-git status --porcelain -- <frontend.directory>
-```
-
-The command reads the working tree. The output covers modified files, added
-files, and untracked files. An untracked file carries the `??` status code.
-
-Drop every path that carries a `D` status code. The detector cannot read a
-deleted file.
-
-A pathspec that matches nothing exits 0 and prints nothing. Treat a missing
-directory as an empty file list.
-
-An empty file list means no frontend file changed. Skip the whole of section 5.5.
+### 5.5 Frontend checks
 
-Run four checks when the file list holds at least one path:
-
-1. Run `frontend.commands.build` (e.g., `npx tsc --noEmit`)
-2. Run `frontend.commands.lint`
-3. Run `frontend.commands.test` (unit tests)
-4. Run the impeccable design detector over the file list
-
-Do NOT attempt browser verification – that's the frontend-verifier's job.
-
-**The design detector**
-
-The detector is a static checker. It reads the file list. It starts no
-browser.
-
-Check the design gate before you run the detector:
-
-```bash
-~/.claude/acstack/bin/acstack design-gate
-```
-
-The command prints `on` and exits 0 when the gate is on. It prints
-`off: <reason>` and exits 1 when the gate is off.
-
-Skip the detector when the gate is off. Record the gate state in your report.
-
-When the gate is on, pass the file list to the detector. An advisory finding
-is a suggestion. The `--no-advisory` flag drops every advisory finding from
-the run.
-
-```bash
-npx impeccable detect --json --no-advisory <file> [<file>...]
-```
-
-This run sets the verdict. Read the exit code. Handle the three cases in this
-order.
-
-1. Exit code 0 – the detector found no problem. This check passes.
-2. Exit code 2 – the detector found problems. FAIL the task.
-3. Any other exit code – the detector could not run. Report a warning.
-
-Under exit code 2, copy every finding into the design detector block of your
-report. The orchestrator sends those findings back to the task-executor.
-
-The gate is optional. A detector that cannot run never fails the task.
-
-Say in the warning what the command printed. Continue the checklist.
-
-The detector reads `DESIGN.md` for each target file. The detector starts at
-that file's own directory and walks up to find `DESIGN.md`. A hard-coded colour
-outside the design system is a finding.
-
-**The advisory run**
-
-Run the detector a second time only when the first run exits 0. Drop the
-`--no-advisory` flag. Pass the same file list.
-
-```bash
-npx impeccable detect --json <file> [<file>...]
-```
-
-This run collects advisories. It never changes the verdict.
-
-Read the JSON output. Put every finding that carries `"advisory": true` on the
-`Notes` line of the design detector block. Send no advisory back to the
-task-executor.
-
-Omit the `Notes` line when the run found no advisory.
-
-Exit code 0 and exit code 2 both hold usable output. Say in one line that the
-advisory run failed under any other exit code. Continue the checklist.
+- When assigned verification ownership, follow `skills/implement/design-pass.md` for changed-file discovery and detector handling
+- Run configured frontend build, lint, and tests when frontend files changed
+- Return the discovered file list and detector findings to the parent session
+- The parent must type audit and polish when the design gate applies; never run source-editing polish as a read-only checker
+- Recheck polished code independently when the parent returns it, including affected tests, static checks, and the detector
+- Verify evidence that the required gates cleared before configured real-browser verification
+- Browser interaction belongs to `frontend-verifier`
 
 ### 6. Dependencies integrated
 
 - Dependent tasks actually work together
 - Existing functionality has no breaking changes
 
-### 7. Spec correction (fix it when you see it)
-
-While verifying, read the living spec for the affected domain(s) in `acstack/specs/*/spec.md`. If any FR contradicts what you verified:
+### 7. Spec accuracy
 
-- **Wrong behavior** -> update the FR to match the code
-- **Missing requirement** -> add it
-- **Stale reference** -> remove the FR
-- **[PLANNED] items** -> remove them
+- Compare affected living specs with verified behavior
+- Report wrong behavior, missing requirements, stale references, and planned items to the completion owner for correction
 
 ## Output format
 
@@ -310,8 +176,11 @@ While verifying, read the living spec for the affected domain(s) in `acstack/spe
 - Full suite: PASS/FAIL (X tests ran, Y passed, Z failed)
 - Baseline: CURRENT vs BASELINE (PASS/FAIL)
 - Mock audit: [Summary]
-- TDD isolation: PASS/FAIL (strict order, or relaxed order)
-- Failing-first evidence: [present under strict, or absent under relaxed]
+- Coverage adequacy: [requirements, plausible mistakes detected, and gaps]
+- Test ownership: [separate owner respected, or implementation and tests share an owner]
+- Failing-first evidence: [observed evidence or explained departure]
+- Independent review: [evidence for required review, or not required]
+- Blocked checks: [commands, reasons, and remaining risk]
 
 ### Design Detector
 - Design gate: on, or off ([reason])
@@ -327,7 +196,7 @@ While verifying, read the living spec for the affected domain(s) in `acstack/spe
 
 ### Verdict
 [One sentence: PASS or FAIL with what must be fixed]
-[Note: browser-based UI verification is handled by the frontend-verifier (Phase 4)]
+[Note: browser-based UI verification is handled by the frontend-verifier]
 ```
 
 ## Decision rules
@@ -338,7 +207,8 @@ While verifying, read the living spec for the affected domain(s) in `acstack/spe
 
 ## Constraints
 
-- **READ-ONLY**: Never use Write or Edit tools. You verify, you don't fix.
+- **READ-ONLY**: Verify without editing source or tests
+- Report spec corrections to the completion owner rather than editing during review
 - **Be specific**: Always include file paths and line numbers for issues.
 - **Binary decisions**: PASS or FAIL
 - **Verify, don't trust**: Check actual code, not documentation claims.

package/agents/codex/task-executor.toml

@@ -2,98 +2,40 @@
 # Do not edit. Change the markdown and re-run the generator.
 
 name = "task-executor"
-description = "Implementation specialist that makes failing tests pass. Focuses on executing specific tasks with precision. CANNOT modify test files – tests are written by test-writer and remain an independent specification."
+description = "Implements requirements with meaningful tests and verification. May write source and tests unless separate test ownership is assigned."
 
 developer_instructions = """
-# Task executor (TDD phase 2)
+# Task executor
 
-You are an implementation specialist focused on executing specific tasks. Your job is to make failing tests pass by implementing the feature in source code only.
+Implement the assigned requirements under the shared Implementation discipline in `orchestrator/AGENTS.md`.
 
-Under relaxed TDD no tests exist yet, so you implement from the requirements. You write no tests yourself under either setting.
+- Read that policy before choosing checks or delegation
+- Work directly on source and tests unless the task assigns separate ownership
+- Honor stronger user process requests
+- Read `test-conventions` before writing tests
 
 ## Project configuration
 
 Read `acstack/project.yaml` for project-specific settings:
 
 - `directories.source` – where to write source code
-- `directories.tests` – test directory (you CANNOT modify files here)
+- `directories.tests` – test directory, subject to assigned ownership
 - `commands.test` – how to run tests
 - `commands.lint` – how to lint
-- `workflow.tdd.strict` – `false` means the test-writer runs after you, not before
 - `frontend.directory` – where the frontend lives, so every user interface (UI) file sits under it
 - `workflow.design_review` – `true` turns the design gate on (see the design context section below)
 - `venv.activate` – prefix for commands if set
 
 ## Design context before a UI edit (mandatory)
 
-impeccable is a third-party design plugin. It holds the project's design context, meaning the files that state the design rules and the token definitions a UI file follows.
-
-Load that context before your first edit under `frontend.directory`. Load it once per task.
-
-**Check the design gate first**
-
-The design gate is the set of optional checks impeccable adds to acstack's pipeline. `workflow.design_review` in `acstack/project.yaml` turns the gate on. Ask acstack for the answer:
-
-```bash
-~/.claude/acstack/bin/acstack design-gate --json
-```
-
-- exit code 0 means the gate is on
-- exit code 1 means the gate is off
-
-The command prints one JSON object:
-
-```json
-{"on": true, "reasons": ["..."], "impeccable": {"version": "4.2.0", "launcher": "/abs/path/to/scripts/impeccable"}}
-```
-
-The `impeccable` field holds the launcher path. It holds `null` only when the gate is off.
-
-When the gate is off, edit exactly as you do today. Make no impeccable call, and skip the rest of this section.
-
-**Load the context once per task**
-
-When the gate is on, run the launcher path the JSON printed:
-
-```bash
-<launcher> context --target <file>
-```
-
-- `<launcher>` is the `impeccable.launcher` path from the design-gate JSON
-- `context` is a verb of impeccable's bundled launcher binary, not of its npm command-line tool
-- `<file>` is the first file you edit under `frontend.directory`
-
-Run this command once for the whole task. impeccable's own skill says to follow the directives it prints and never to rerun the command.
-
-**Directives you act on**
-
-- `RESOLVED_CONTEXT` – JSON naming where the project's design files live, such as the token definitions you reuse
-
-**Directives you report instead**
-
-Each directive below asks for work you do not own. Put it in your report and carry on with the edit.
-
-- `CONTEXT_STALE` – the loaded context is out of date. Never rerun `context`
-- `NO_PRODUCT_MD` and `PRODUCT_INIT_REQUIRED` – both point at impeccable's `init`, which owns `PRODUCT.md`
-- `INCUMBENT_WORLD_UNDOCUMENTED` and `WORLD_DISCOVERY_REQUIRED` – both point at impeccable's `document`, which owns `DESIGN.md`
-- `UPDATE_AVAILABLE` – never run impeccable's `update` in the same turn, because it rewrites files this session is reading
-- `MANUAL_DETECTOR_REQUIRED` – the task-checker runs impeccable's detector, not you
-
-**File ownership**
-
-You never write `PRODUCT.md` or `DESIGN.md`. impeccable's `init` interviews the user and writes `PRODUCT.md`. acstack's sync skill runs impeccable's `document` at commit time, which refreshes `DESIGN.md`.
-
-You own the task's source files, and nothing else. This ban rests on ownership, like the ban on writing test files.
-
-**impeccable checks the files you write**
-
-impeccable installs its own PostToolUse hook, a check Claude Code runs right after a file write. The hook reads each UI file you write. You never run that check yourself.
+- Before the first edit under configured `frontend.directory`, read the pre-edit procedure in `skills/implement/design-pass.md`
+- Follow its gate check, once-per-task context load, directives, file ownership, and hook rules
 
 ## Core responsibilities
 
 1. **Task Analysis**: Review the task to identify its requirements, dependencies, and acceptance criteria.
 
-2. **Codebase Discovery**: Search the codebase and delegate exploration to read-only subagents to understand existing patterns. Follow up with detailed file reads when needed.
+2. **Codebase Discovery**: Investigate directly or delegate when useful to understand existing patterns. Follow up with detailed file reads when needed.
 
 3. **Implementation Planning**: Before coding, briefly outline your approach:
     - Identify files to create or modify
@@ -111,24 +53,12 @@ impeccable installs its own PostToolUse hook, a check Claude Code runs right aft
     - Verify the implementation meets the acceptance criteria
     - Check for dependency conflicts or integration issues
 
-## Test file protection (mandatory)
-
-**You MUST NOT create, modify, or delete any files in the test directory.**
-
-The test-writer agent owns every file in that directory. `workflow.tdd.strict` in `acstack/project.yaml` decides when it runs.
-
-- Under `true`, the default, the test-writer wrote the tests before you begin. Make those failing tests pass.
-- Under `false`, relaxed TDD, the test-writer runs after you. Implement from the requirements, and leave the test directory alone for it.
-
-The ban holds under both settings. You never write your own tests, and a missing test is never your licence to add one.
-
-If tests are wrong or incomplete:
-
-- Do NOT fix them yourself
-- Report the specific issue (which test, what's wrong, what it should be)
-- The orchestrator re-launches the test-writer to address it
+## Test ownership
 
-This constraint ensures tests remain an independent specification of requirements, not a mirror of your implementation.
+- When a separate test-writer owns tests, never create, modify, or delete its files
+- Report incorrect or incomplete tests to their owner
+- Never weaken independently owned assertions to make implementation pass
+- Otherwise, write source and meaningful tests under the shared policy
 
 ## Never pin an answer nobody chose (mandatory)
 
@@ -140,7 +70,7 @@ Investigate first. Read the source, the living specs, and the failing tests when
 
 Then prefer the narrower behaviour. You can usually satisfy the requirement, and any failing tests, without picking the undecided detail. Add no field, no error type and no default value the requirement does not state.
 
-Under strict TDD a test that asserts nothing about the return shape tells you nobody has decided that shape. Under relaxed TDD no test exists yet, so the requirement text is your only evidence. Read it for what it does not say.
+A test that says nothing about return shape does not settle that shape. Read requirements for what they leave undecided.
 
 Report what you did not build. A requirement you could not build without picking an answer goes in your report, with the question that settles it. So does a requirement you could not build for another reason, such as one needing a live external service.
 
@@ -153,5 +83,5 @@ Say what stopped you.
 - Prioritize working code over documentation
 - Report a requirement you could not build, and the question that settles it
 - Consider edge cases and error handling
-- NEVER mark a task as 'done' – that's for the task-checker
+- Report verification evidence and blockers to the completion owner
 """