@orkestrel/scaffold 0.0.21 → 0.0.23
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/bin/scaffold.js +371 -140
- package/dist/bin/scaffold.js.map +1 -1
- package/dist/host/AGENTS.md +61 -42
- package/dist/host/CLAUDE.md +39 -408
- package/dist/host/agents/orchestration.md +454 -0
- package/dist/host/agents/skills/enterprise-bootstrap/SKILL.md +25 -7
- package/dist/host/agents/skills/orkestrel-align-packages/SKILL.md +2 -2
- package/dist/host/agents/skills/orkestrel-build-application/SKILL.md +42 -31
- package/dist/host/agents/skills/orkestrel-build-application/references/application.md +129 -0
- package/dist/host/agents/skills/orkestrel-debrief/SKILL.md +3 -3
- package/dist/host/agents/skills/orkestrel-debrief/references/field-testing.md +2 -2
- package/dist/host/agents/skills/orkestrel-falsify/SKILL.md +167 -0
- package/dist/host/agents/skills/orkestrel-falsify/references/brief.md +98 -0
- package/dist/host/agents/skills/orkestrel-falsify/references/reconcile.md +148 -0
- package/dist/host/agents/skills/orkestrel-harden-package/SKILL.md +4 -2
- package/dist/host/agents/skills/orkestrel-harden-package/references/centralization.md +5 -5
- package/dist/host/agents/skills/orkestrel-harden-package/references/research.md +2 -0
- package/dist/host/agents/skills/orkestrel-polish-surface/SKILL.md +11 -6
- package/dist/host/claude/agents/analyst.md +59 -0
- package/dist/host/claude/agents/application.md +1 -1
- package/dist/host/claude/agents/builder.md +1 -1
- package/dist/host/claude/agents/checker.md +5 -1
- package/dist/host/claude/agents/codex.md +120 -94
- package/dist/host/claude/agents/grok.md +44 -32
- package/dist/host/claude/agents/implementer.md +1 -1
- package/dist/host/claude/agents/orkestrel.md +5 -5
- package/dist/host/claude/agents/planner.md +9 -3
- package/dist/host/claude/agents/researcher.md +6 -5
- package/dist/host/claude/agents/reviewer.md +12 -6
- package/dist/host/claude/agents/scout.md +7 -4
- package/dist/host/claude/agents/verifier.md +1 -1
- package/dist/host/claude/rules/application.md +17 -16
- package/dist/host/claude/rules/architecture.md +41 -22
- package/dist/host/claude/rules/documentation.md +2 -1
- package/dist/host/claude/rules/names.md +7 -6
- package/dist/host/claude/rules/quality.md +65 -18
- package/dist/host/claude/rules/styles.md +1 -1
- package/dist/host/claude/rules/tests.md +12 -6
- package/dist/host/claude/rules/typescript.md +1 -1
- package/dist/host/claude/rules/workspace.md +6 -3
- package/dist/host/claude/settings.json +2 -0
- package/dist/host/claude/skills/orkestrel-falsify/SKILL.md +10 -0
- package/dist/host/codex/agents/analyst.toml +13 -4
- package/dist/host/codex/agents/checker.toml +1 -1
- package/dist/host/codex/agents/grok.toml +2 -1
- package/dist/host/codex/agents/opus.toml +1 -1
- package/dist/host/codex/agents/planner.toml +1 -1
- package/dist/host/codex/agents/researcher.toml +2 -2
- package/dist/host/codex/agents/reviewer.toml +1 -1
- package/dist/host/codex/agents/scout.toml +2 -2
- package/dist/host/codex/config.toml +23 -70
- package/dist/host/cursor/rules/orchestration.mdc +33 -0
- package/dist/host/guides/src/scaffold.md +339 -125
- package/dist/host/manifest.json +47 -1
- package/dist/host/tests/setupPolicy.ts +210 -3
- package/dist/src/core/index.cjs +477 -69
- package/dist/src/core/index.cjs.map +1 -1
- package/dist/src/core/index.d.cts +132 -43
- package/dist/src/core/index.d.ts +132 -43
- package/dist/src/core/index.js +474 -70
- package/dist/src/core/index.js.map +1 -1
- package/dist/src/server/index.cjs +83 -33
- package/dist/src/server/index.cjs.map +1 -1
- package/dist/src/server/index.d.cts +43 -27
- package/dist/src/server/index.d.ts +43 -27
- package/dist/src/server/index.js +84 -35
- package/dist/src/server/index.js.map +1 -1
- package/package.json +4 -4
|
@@ -0,0 +1,129 @@
|
|
|
1
|
+
# Application architecture reference
|
|
2
|
+
|
|
3
|
+
## Environment selection
|
|
4
|
+
|
|
5
|
+
Support application-only, source-only, and mixed workspaces.
|
|
6
|
+
The CLI uses `--src core,browser,server` for published src environments and
|
|
7
|
+
`--app core,browser,server` for private app environments. At least one selector
|
|
8
|
+
is required in non-interactive creation; `--surfaces` is not part of the
|
|
9
|
+
vocabulary.
|
|
10
|
+
|
|
11
|
+
| Selection | Contract |
|
|
12
|
+
| ----------- | ------------------------------------------------------ |
|
|
13
|
+
| app/core | Host-independent contracts and composition |
|
|
14
|
+
| app/browser | Vue browser runtime and real-browser tests |
|
|
15
|
+
| app/server | Node runtime, executable CJS build, and loopback tests |
|
|
16
|
+
|
|
17
|
+
Core-only, browser-only, and server-only are valid. A browser+server pair must
|
|
18
|
+
include app/core so shared transport contracts have one host-independent owner.
|
|
19
|
+
|
|
20
|
+
## Dependency direction
|
|
21
|
+
|
|
22
|
+
- app/core imports no DOM, Node, app/browser, or app/server implementation.
|
|
23
|
+
- app/browser may import app/core and published browser/core packages.
|
|
24
|
+
- app/server may import app/core and published server/core packages.
|
|
25
|
+
- Published src environments never import private app modules. Src core is
|
|
26
|
+
host-independent; src browser/server may import src core and remain
|
|
27
|
+
mutually disjoint.
|
|
28
|
+
- Apply the same direction to cross-package `@orkestrel/<package>/browser` and
|
|
29
|
+
`/server` exports; a package's bare export is its core API.
|
|
30
|
+
- Browser code reaches server behavior through app/core contracts and a
|
|
31
|
+
transport boundary, never by importing app/server.
|
|
32
|
+
- Every environment barrel contains `export *` declarations only. A star-export
|
|
33
|
+
collision is a design failure to be renamed at its owner, never hidden behind
|
|
34
|
+
a selective barrel row.
|
|
35
|
+
- Types, constants, helpers, validators, parsers, and factories live in their
|
|
36
|
+
centralized kind files; an implementation file holds one class plus imports.
|
|
37
|
+
`ApplicationServerRunner` lives alone in `ApplicationServerRunner.ts` and
|
|
38
|
+
`startApplicationServer` in `factories.ts`; `main.ts` owns no reusable
|
|
39
|
+
declarations.
|
|
40
|
+
- Enforcement is layered, and each layer owns exactly what it can express:
|
|
41
|
+
- `.oxlintrc.json` `no-restricted-imports` owns **literal-string** declared
|
|
42
|
+
package, alias, and conventional relative imports, in both directions.
|
|
43
|
+
`.oxfmtrc.json` owns formatting. Neither replaces the other, and neither
|
|
44
|
+
replaces typechecking.
|
|
45
|
+
- `tests/setupPolicy.ts` owns what Oxlint cannot represent: computed and
|
|
46
|
+
template-literal import specifiers, declaration placement, and the
|
|
47
|
+
export-star barrel law. It is a deliberately narrow TypeScript-compiler pass
|
|
48
|
+
over the repository's own coding laws — not a general-purpose analyzer, and
|
|
49
|
+
not a second linter.
|
|
50
|
+
- Scoped TypeScript projects remove Node/DOM globals from the wrong
|
|
51
|
+
environment.
|
|
52
|
+
- Vite's real browser/server builds resolve Vue, assets, CSS, workers, and
|
|
53
|
+
runtime module graphs, and its generated environment-boundary plugin checks
|
|
54
|
+
dependency direction and physical workspace containment on the actual graph.
|
|
55
|
+
Vite's parsed HTML asset callbacks reject forced inlining before any direct
|
|
56
|
+
asset read; non-inlined output assets are audited by physical source path.
|
|
57
|
+
- Generated-consumer lint, typecheck, build, and integration tests prove the
|
|
58
|
+
combined configuration.
|
|
59
|
+
- Do not add a second general-purpose parser, source-language analyzer, or
|
|
60
|
+
boundary script that duplicates a layer above. Use the toolchain's own
|
|
61
|
+
facilities instead: Vite's Oxc/Rolldown AST for TypeScript and JavaScript
|
|
62
|
+
asset references, the official Vue SFC compiler for `.vue` blocks, Vite's
|
|
63
|
+
HTML parser callbacks, its bundled Lightning CSS dependency analyzer, and the
|
|
64
|
+
TypeScript compiler API for the narrow coding-law pass.
|
|
65
|
+
- Include `.ts`, `.tsx`, `.mts`, and `.cts` in every scoped TypeScript check.
|
|
66
|
+
Vue SFCs belong only to app/browser. CSS is the generated browser style
|
|
67
|
+
format; SCSS requires an explicitly authorized Sass compiler dependency.
|
|
68
|
+
|
|
69
|
+
## Entries and configuration
|
|
70
|
+
|
|
71
|
+
- Every selected app environment has an `index.ts` barrel.
|
|
72
|
+
- app/browser executes from `main.ts` through `index.html`.
|
|
73
|
+
- app/server centralizes process signals in an explicitly stoppable runner,
|
|
74
|
+
returns that runner from convenience startup so cleanup is never hidden, and
|
|
75
|
+
executes it from a declaration-free `main.ts`; its bundle is
|
|
76
|
+
`dist/app/server/main.cjs`, with only `node:*` external.
|
|
77
|
+
- app/core is check/test-only.
|
|
78
|
+
- Root `tsconfig.json` owns `@app/*` aliases.
|
|
79
|
+
- Root `vite.config.ts` owns shared config and Vitest projects.
|
|
80
|
+
- `configs/app` contains thin target wrappers and scoped tsconfigs.
|
|
81
|
+
- app/browser uses `vue-tsc`; other app environments use `tsc`.
|
|
82
|
+
|
|
83
|
+
## Manifest policy
|
|
84
|
+
|
|
85
|
+
- App-only: unscoped name, `private: true`, no package `main`, `module`,
|
|
86
|
+
`types`, `exports`, or public `publishConfig`.
|
|
87
|
+
- Mixed: normal published source entries; package files include `dist/src` and
|
|
88
|
+
exclude `dist/app`.
|
|
89
|
+
- Add Vue only to development tooling when app/browser is selected; mixed
|
|
90
|
+
publication must not expose an app-only Vue runtime dependency.
|
|
91
|
+
- Add no product-specific dependencies or optional showcase tooling by default.
|
|
92
|
+
|
|
93
|
+
## Boundaries and tests
|
|
94
|
+
|
|
95
|
+
- Default server host is loopback.
|
|
96
|
+
- Parse the options container and host/port leaves before mutation; reject
|
|
97
|
+
wrong-shaped containers, empty hosts, and non-integer, negative, or
|
|
98
|
+
out-of-range ports with a coded error and guard.
|
|
99
|
+
- Lifecycle transitions serialize in call order, ephemeral restarts re-request
|
|
100
|
+
port zero, server stop closes hostile active connections deterministically,
|
|
101
|
+
and runner stop idempotently releases its SIGINT/SIGTERM listeners. Runner
|
|
102
|
+
generations isolate asynchronous failures so an older transition cannot
|
|
103
|
+
release a newer run's listeners.
|
|
104
|
+
- Real child-process tests prove executable readiness, collision exit, signal
|
|
105
|
+
termination, and port release. On Windows, `ChildProcess.kill('SIGTERM')`
|
|
106
|
+
reports OS termination by signal; POSIX delivery exercises the runner's
|
|
107
|
+
graceful signal listener and exits zero.
|
|
108
|
+
- Browser tests use Playwright-backed Vitest Browser Mode and real DOM. A
|
|
109
|
+
browser-capability check probes the installed executable directly with
|
|
110
|
+
`existsSync(chromium.executablePath())`; there is no channel or environment
|
|
111
|
+
guessing.
|
|
112
|
+
- Server tests bind port zero on loopback and use real fetch requests.
|
|
113
|
+
- Capability-dependent tests probe the actual capability and scope any skip.
|
|
114
|
+
- The generated browser application disables the public directory so an
|
|
115
|
+
unmanaged file copy cannot bypass the module graph or its boundary checks.
|
|
116
|
+
- Generated CI runs the gates on the declared minimum Node release and on the
|
|
117
|
+
current major.
|
|
118
|
+
- Guide parity walks existing `src` and/or `app` roots and maps every selected
|
|
119
|
+
`@src/*` / `@app/*` alias.
|
|
120
|
+
|
|
121
|
+
## Cleanup before gates
|
|
122
|
+
|
|
123
|
+
- Source: no stray or misplaced declarations, non-exported centralized
|
|
124
|
+
declarations, nested function declarations, duplicate implementations,
|
|
125
|
+
superfluous wrappers, compatibility aliases, or stale imports and barrel rows.
|
|
126
|
+
- Tests: no unused or duplicated helpers, empty setup files, placeholder suites,
|
|
127
|
+
current-scope `.todo` / `.skip`, or assertions that cannot fail.
|
|
128
|
+
- Text: UTF-8 only; scan generated or migrated edits for replacement characters,
|
|
129
|
+
mojibake, and stray control characters.
|
|
@@ -18,9 +18,9 @@ Read the current files in this order:
|
|
|
18
18
|
pass of an agent-facing surface.
|
|
19
19
|
4. `guides/README.md`, the governing guides for what the campaign built, and `ROADMAP.md`.
|
|
20
20
|
|
|
21
|
-
The user's current instruction wins. The debrief judges the artifact
|
|
22
|
-
produced it; neither is exempt
|
|
23
|
-
a practice that worked
|
|
21
|
+
The user's current instruction wins. The debrief judges the artifact and the process that
|
|
22
|
+
produced it; neither is exempt. Capture successes as deliberately as mistakes, and codify
|
|
23
|
+
a practice that worked so it repeats.
|
|
24
24
|
|
|
25
25
|
## The debrief laws
|
|
26
26
|
|
|
@@ -10,8 +10,8 @@ Test from the top down, and do not stop at the tier that passes:
|
|
|
10
10
|
1. **Frontier** (the harness's default model) — proves the surface works at all.
|
|
11
11
|
2. **Mid tier** (e.g. a codex mechanical model) — proves the surface survives a harness's
|
|
12
12
|
schema abbreviation and a model that reads less carefully.
|
|
13
|
-
3. **Small harness-native** (e.g. Haiku, a codex high-volume model
|
|
14
|
-
|
|
13
|
+
3. **Small harness-native** (e.g. Haiku, a codex high-volume model) — the acceptance
|
|
14
|
+
tier: these must walk the surface unaided, or the surface is not done.
|
|
15
15
|
4. **Local floor** (a quantized 2B-class model through a real tool-calling client) — not
|
|
16
16
|
an acceptance gate; a stochastic probe that exposes teaching gaps nothing else hits.
|
|
17
17
|
Its residual failures must be provably consumer-floor (malformed emission, attention
|
|
@@ -0,0 +1,167 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: orkestrel-falsify
|
|
3
|
+
description: Run an adversarial audit round against work that already looks finished — write the subject as numbered falsifiable claims, dispatch independent auditors instructed to break them rather than confirm them, reconcile their evidence, and rule. Use before accepting a fix round, before a version bump or publication, when green gates are the only evidence a change works, when a defect has recurred across rounds, or whenever a review would otherwise read a diff and agree with it.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Falsify
|
|
7
|
+
|
|
8
|
+
Green gates prove a suite ran. They prove nothing about the claim the work makes. This skill is for
|
|
9
|
+
the moment when everything passes and the work is still not known to be right.
|
|
10
|
+
|
|
11
|
+
## Load authority
|
|
12
|
+
|
|
13
|
+
1. `AGENTS.md`.
|
|
14
|
+
2. `.claude/rules/quality.md`, especially **Falsification** — the laws governing auditor behaviour.
|
|
15
|
+
This skill prescribes the round; that section prescribes the conduct inside it. Do not restate it.
|
|
16
|
+
3. The governing guide/spec for the subject.
|
|
17
|
+
4. `references/brief.md` before writing a brief; `references/reconcile.md` before ruling.
|
|
18
|
+
|
|
19
|
+
## When a round is warranted
|
|
20
|
+
|
|
21
|
+
Run one when the work is finished and the evidence is weak in a specific way:
|
|
22
|
+
|
|
23
|
+
- gates are green and nothing has attacked the claim;
|
|
24
|
+
- a fix round is about to be accepted, especially one whose author reported success;
|
|
25
|
+
- a version is about to be bumped, packed, or published;
|
|
26
|
+
- the same defect class has now appeared in more than one round;
|
|
27
|
+
- a self-declared "sound, unchanged, no fix needed" verdict is load-bearing.
|
|
28
|
+
|
|
29
|
+
Do not run one for a typo, a mechanical rename, or work whose failure would be immediately visible.
|
|
30
|
+
|
|
31
|
+
A round also needs something new to attack. When the previous round's claims all held, nothing has
|
|
32
|
+
been added or repaired since, and the only motive is that an auditor could still imagine an attack,
|
|
33
|
+
there is no subject — closing is the correct action and the next subject is the deliverable.
|
|
34
|
+
|
|
35
|
+
## Write the brief
|
|
36
|
+
|
|
37
|
+
The brief is the instrument. A weak brief produces a confirming review no matter which auditor reads
|
|
38
|
+
it. Follow `references/brief.md`. What this skill adds beyond the conduct law:
|
|
39
|
+
|
|
40
|
+
- Every re-run is a **successor**, not a restatement. It carries what the previous round closed so
|
|
41
|
+
nothing is re-reported, and it adds claims that attack **the previous round's own rulings**.
|
|
42
|
+
- The brief names what the round **decides**. An auditor that does not know the stakes calibrates to
|
|
43
|
+
politeness.
|
|
44
|
+
- Unknowns are named as unknowns, with how the auditor reports back on them.
|
|
45
|
+
|
|
46
|
+
The claim form itself is the Falsification law's — read it there. The **verdict shape** below is this
|
|
47
|
+
skill's, because `.agents/orchestration.md` assigns it here; everything else about auditor conduct is the law's.
|
|
48
|
+
|
|
49
|
+
## Evidence, by subject type
|
|
50
|
+
|
|
51
|
+
The brief supplies the evidence its subject actually has. Requiring a diff for a subject that has no
|
|
52
|
+
diff is a rule the brief cannot satisfy.
|
|
53
|
+
|
|
54
|
+
| subject | required evidence |
|
|
55
|
+
| --------------------------------------- | ------------------------------------------------------------------------------------- |
|
|
56
|
+
| a code change | the actual diff and the actual status output; omitting either is a dispatch deviation |
|
|
57
|
+
| a rendered or externally driven surface | the capture portfolio as primary, source as corroboration |
|
|
58
|
+
| a policy, design, or process proposal | the proposal, the canon it must satisfy, and the record of what motivated it |
|
|
59
|
+
|
|
60
|
+
**A subject can occupy more than one row; supply every row it occupies.** A ruling whose fixes
|
|
61
|
+
already landed as edits is both the third row and the first, and withholding the diff on the grounds
|
|
62
|
+
that the subject is "a proposal" leaves the auditor unable to check whether a fix changed anything
|
|
63
|
+
nobody claimed.
|
|
64
|
+
|
|
65
|
+
## Run the round
|
|
66
|
+
|
|
67
|
+
- **Verify every authority the brief references exists in the tree the auditor is rooted in.** A
|
|
68
|
+
brief that points at a rule file, section, or guide the executor cannot find delivers nothing while
|
|
69
|
+
looking like authority — and it fails silently, because an auditor does not report a heading it
|
|
70
|
+
never saw. Check before dispatch; propagate the missing file rather than restating its contents in
|
|
71
|
+
the brief. This is the reason restatement felt necessary, and it is the wrong cure.
|
|
72
|
+
- Run the **two-lane adversarial pass** on one identical brief: a subjective lane and an objective
|
|
73
|
+
lane, each a fresh subagent with a clean context, blind to each other. Reconcile them yourself.
|
|
74
|
+
`.agents/orchestration.md` owns lane definitions, engine assignment, and what happens when an
|
|
75
|
+
engine is dark; do not restate them here.
|
|
76
|
+
- A round run with one lane is a deviation. Record it rather than glossing it. If an engine is
|
|
77
|
+
unavailable, the remaining engine runs both lanes — it never drops one.
|
|
78
|
+
- **Give every auditor the means to run its attacks.** A lens that can only read returns derivations,
|
|
79
|
+
and a derivation reads exactly like a verdict — it will confirm a claim that one probe would break.
|
|
80
|
+
- **Tell each auditor exactly where a probe may live, and verify that place works before you say it.**
|
|
81
|
+
A test runner resolves only what its own configuration includes: a probe written outside the project
|
|
82
|
+
root is typically not discovered at all, and the run reports no test files rather than a result. The
|
|
83
|
+
reliable form is a file inside the canonical mirrored suite, run by explicit path, deleted before the
|
|
84
|
+
auditor returns — promoted into a permanent test when it proves something worth keeping. Give each
|
|
85
|
+
concurrent auditor a distinct filename that already satisfies the repository's test naming
|
|
86
|
+
convention; never invent a prefix to dodge collisions, and never let two auditors claim one path. A
|
|
87
|
+
leaked probe is discovered by the suite and fails a run nobody else caused.
|
|
88
|
+
- **Run auditors concurrently only when their writes cannot collide.** Read-only lenses still write
|
|
89
|
+
probes; give each a distinct path and forbid whole-project runs, or serialize the round. **This binds
|
|
90
|
+
the orchestrator too:** a tree-wide gate run while a round is live sees the auditors' in-flight probes
|
|
91
|
+
and reports a failure nobody caused. Wait for the round, or scope the command to paths no auditor
|
|
92
|
+
owns. Never delete another executor's working file to make your own command pass.
|
|
93
|
+
- Supply the evidence the subject type requires, per the table above.
|
|
94
|
+
- Auditors are read-only and spawn nothing.
|
|
95
|
+
- Blind reports are **immutable**. Nothing an auditor returns is edited, merged, or revised — by
|
|
96
|
+
anyone, including the auditor — once it has been returned.
|
|
97
|
+
|
|
98
|
+
## Verdict shape
|
|
99
|
+
|
|
100
|
+
Every auditor in every round returns exactly this, and nothing else. One shape makes rounds
|
|
101
|
+
comparable; a round that invents its own cannot be read against the last one.
|
|
102
|
+
|
|
103
|
+
1. **Numbered verdicts**, one per claim, in the brief's order. Exactly one of four values:
|
|
104
|
+
|
|
105
|
+
| value | meaning | evidence |
|
|
106
|
+
| --------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
107
|
+
| `CONFIRMED` | attacked and it held | as the Falsification law requires |
|
|
108
|
+
| `BROKEN` | falsified | as the Falsification law requires — note it says _input, **state, or interleaving**_, so a concurrency claim is falsified by an interleaving, not by an input |
|
|
109
|
+
| `UNRESOLVED` | cannot be decided from the evidence available | what would settle it |
|
|
110
|
+
| `NOT-EVIDENCED` | a claim about a rendered or externally driven surface the supplied capture cannot show | which capture is missing |
|
|
111
|
+
|
|
112
|
+
The first two rows defer; only the last two are this skill's, because the law does not name them.
|
|
113
|
+
`BROKEN` and `UNRESOLVED` are **separate**: a claim nobody could decide has not been falsified,
|
|
114
|
+
and it cannot supply the fields falsification requires. `NOT-EVIDENCED` is the token the
|
|
115
|
+
`analyst` and `reviewer` charters already require; it is kept, not re-invented.
|
|
116
|
+
|
|
117
|
+
2. **Findings fitting no claim**, if any, each substantiated to the same standard as `BROKEN`.
|
|
118
|
+
|
|
119
|
+
3. **One terminal line**, and only one:
|
|
120
|
+
|
|
121
|
+
```text
|
|
122
|
+
VERDICT: PASS — <m> of <m> confirmed, no findings outside the claims
|
|
123
|
+
VERDICT: FAIL — <n> broken, <u> unresolved, <e> not-evidenced, <x> findings outside the claims
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
**`PASS` requires all four to be true**: every claim `CONFIRMED`, nothing `UNRESOLVED`, nothing
|
|
127
|
+
`NOT-EVIDENCED`, and no substantiated finding outside the claims. A single substantiated finding
|
|
128
|
+
forces `FAIL` no matter how the numbered claims landed — otherwise a round can report a real
|
|
129
|
+
defect and still emit the word that authorises the release.
|
|
130
|
+
|
|
131
|
+
No process diary. No summary of what was read.
|
|
132
|
+
|
|
133
|
+
## When a round comes back all-confirmed
|
|
134
|
+
|
|
135
|
+
The Falsification law governs this: the brief goes on trial, not the subject. Apply it, and if the
|
|
136
|
+
claims turn out to have been descriptive, the successor brief is where the sharper ones go.
|
|
137
|
+
|
|
138
|
+
## Reconcile and rule
|
|
139
|
+
|
|
140
|
+
Follow `references/reconcile.md`. The obligations that are not delegable:
|
|
141
|
+
|
|
142
|
+
- **Reproduce every sharp finding yourself** before acting on it. An auditor's finding is a
|
|
143
|
+
hypothesis until the orchestrator has run it.
|
|
144
|
+
- **A disagreement between auditors is rarely a tie to average.** It is usually two correct answers
|
|
145
|
+
to two different questions. Find the question each one answered.
|
|
146
|
+
- **Bound every finding**: state what is _not_ broken, and why the adjacent behaviour that looks the
|
|
147
|
+
same is correct. An audit that reports everything is as useless as one that reports nothing.
|
|
148
|
+
- **Bound the fix before briefing it.** Establish what over-correcting would break, and include that
|
|
149
|
+
in the fix brief as a constraint.
|
|
150
|
+
- Drop, on the record, any finding neither auditor can substantiate.
|
|
151
|
+
|
|
152
|
+
## Accept, or run it again
|
|
153
|
+
|
|
154
|
+
The threshold is **a `PASS` terminal line on a brief whose claims cover what the subject owns** —
|
|
155
|
+
every numbered claim `CONFIRMED` on evidence, nothing `UNRESOLVED`, nothing `NOT-EVIDENCED`, no
|
|
156
|
+
substantiated finding beside them. Never green gates, which prove only that a suite ran.
|
|
157
|
+
|
|
158
|
+
A round that finds something is a success, not a delay. The alternative is a consumer finding it
|
|
159
|
+
after publication, when the version number is already spent. But an unsubstantiated attack is not a
|
|
160
|
+
finding, and the supply of imaginable ones never runs out: a round is not re-run because an auditor
|
|
161
|
+
can still think of one. A substantiated finding against something no claim names is real and forces
|
|
162
|
+
`FAIL`; an unsubstantiated one is a claim for the successor brief. The escalation law in
|
|
163
|
+
`.claude/rules/quality.md` governs a subject that keeps producing findings at the same seam — after
|
|
164
|
+
enough of them the ruling owed is on the design, not on the next defect.
|
|
165
|
+
|
|
166
|
+
When a fix round follows, its auditor must be an engine that did not write it, and the next round's
|
|
167
|
+
brief is the successor of this one.
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# Writing the claims brief
|
|
2
|
+
|
|
3
|
+
The brief decides the round. Every weak audit this process has produced was a weak brief read
|
|
4
|
+
faithfully; every finding worth having came from a claim written sharply enough to be attacked.
|
|
5
|
+
|
|
6
|
+
## Anatomy
|
|
7
|
+
|
|
8
|
+
**Subject.** The whole chain, not the last commit. A fix round's defect usually lives in what an
|
|
9
|
+
earlier round assumed, so an audit scoped to the newest diff cannot see it. State the tip, the
|
|
10
|
+
branch, and the chain of rounds with one line each on what each claimed to close.
|
|
11
|
+
|
|
12
|
+
**What the round decides.** Say it plainly — "this decides whether the package is bumped and
|
|
13
|
+
consumed downstream", "this decides whether the fix is accepted". An auditor that does not know the
|
|
14
|
+
stakes calibrates to politeness, and politeness confirms.
|
|
15
|
+
|
|
16
|
+
**Already established — do not re-run.** List what the orchestrator has already verified, so effort
|
|
17
|
+
goes somewhere new and settled findings are not re-reported as fresh. State that these were verified
|
|
18
|
+
by the orchestrator directly rather than taken from a writer's report; an auditor that suspects the
|
|
19
|
+
established list is hearsay will re-derive all of it.
|
|
20
|
+
|
|
21
|
+
**Review evidence.** The actual diff and the actual status output, by path. Omitting either is a
|
|
22
|
+
dispatch deviation. For any claim about a rendered or externally driven surface, the capture is the
|
|
23
|
+
evidence and source is corroboration.
|
|
24
|
+
|
|
25
|
+
**Numbered falsifiable claims.** Each is a property some concrete input, state, or interleaving
|
|
26
|
+
could show false. Assign the primary lane where auditors differ in strength, but do not let an
|
|
27
|
+
auditor skip a claim because it assumes the other covers it better. The claim set is the round's
|
|
28
|
+
scope: write it to cover what the subject owns, then hold it closed. An attack the round invents
|
|
29
|
+
against something no claim names enters the verdict only when it is substantiated to the `BROKEN`
|
|
30
|
+
standard; otherwise it is a claim for the successor brief, not a finding.
|
|
31
|
+
|
|
32
|
+
**Unknowns, named as unknowns.** What the orchestrator does not know that the round needs, and how
|
|
33
|
+
the auditor reports back on it. A brief that cannot be fully specified says so; the alternative is
|
|
34
|
+
an executor inventing an answer and building on it silently.
|
|
35
|
+
|
|
36
|
+
**The threshold.** State that a finding is worth more than a clean pass, and why: the alternative is
|
|
37
|
+
a consumer finding it after publication, when the version is already spent.
|
|
38
|
+
|
|
39
|
+
## The successor rule
|
|
40
|
+
|
|
41
|
+
A re-run **amends**; it never restates. Rewriting a brief from scratch loses the shape of what has
|
|
42
|
+
already been attacked, and the round re-derives it at full cost.
|
|
43
|
+
|
|
44
|
+
A successor brief:
|
|
45
|
+
|
|
46
|
+
- **carries the chain forward** with the new round added to the table;
|
|
47
|
+
- **moves the closed findings into "already established"** so they are not re-reported;
|
|
48
|
+
- **states what changed in the brief itself**, so a reader can see which claims are new;
|
|
49
|
+
- **adds claims that attack the previous round's own rulings.**
|
|
50
|
+
|
|
51
|
+
That last one is the highest-yield idea in this process. A fix round makes _decisions_ — it rules
|
|
52
|
+
that some input should be refused rather than carried, that some widening is deliberate, that some
|
|
53
|
+
site is sound and needs no change. Those rulings are the freshest and least-examined surface in the
|
|
54
|
+
package, and they were made by the engine least able to see their consequences. Write a claim for
|
|
55
|
+
each one.
|
|
56
|
+
|
|
57
|
+
## Claims that repeatedly find things
|
|
58
|
+
|
|
59
|
+
- **"The containment has no remaining door."** Require the auditor to enumerate the surface itself
|
|
60
|
+
rather than trust any registry, table, or sweep the writer produced.
|
|
61
|
+
- **"No refusal was widened into a regression."** Every hardening round risks over-correcting. Ask
|
|
62
|
+
which legitimate caller pattern broke, and require it to be named.
|
|
63
|
+
- **"The instruments bind."** Attack the instrument's _rule_, not its output: name a change it would
|
|
64
|
+
not catch. An instrument nobody has tried to evade is not evidence.
|
|
65
|
+
- **"No instrument is vacuous."** Ask for a control that cannot produce its failing verdict. If a
|
|
66
|
+
previous round shipped one, say so and name it — a round told a tautology already shipped here
|
|
67
|
+
looks harder than one told to check generally.
|
|
68
|
+
- **"The guide is true."** Not plausible — true. Ask specifically whether a false universal has been
|
|
69
|
+
replaced by an **unfalsifiable** one, which is worse, because it reads as rigour.
|
|
70
|
+
- **"The package is coherent as a whole. Would you ship this?"** The only claim that catches
|
|
71
|
+
accumulated damage no single diff shows.
|
|
72
|
+
- **"The self-declared sound-and-unchanged verdicts are sound."** A writer's table saying a site
|
|
73
|
+
needed no change is a claim like any other, made by the party least able to test it. Require the
|
|
74
|
+
auditor to pick the ones it considers most likely wrong and actually attack them, and say how many.
|
|
75
|
+
|
|
76
|
+
## Instructions that change auditor behaviour
|
|
77
|
+
|
|
78
|
+
- _"CONFIRMED requires naming the attack you tried that failed."_ — the single most effective
|
|
79
|
+
sentence, because it converts a confirmation from an opinion into a report of work done.
|
|
80
|
+
- _"A claim you cannot decide is UNRESOLVED, not CONFIRMED — say what would settle it."_
|
|
81
|
+
- _"Assume this chain has one more."_ — with the count of prior rounds and how many were provoked by
|
|
82
|
+
a defect the previous round believed closed.
|
|
83
|
+
- _"Do not hedge toward an imagined consensus."_ — when two auditors run blind, each will otherwise
|
|
84
|
+
soften toward what it guesses the other said.
|
|
85
|
+
|
|
86
|
+
Do **not** write _"an audit returning only confirmations has not tried."_ It reads as pressure to
|
|
87
|
+
produce a finding, and an auditor that manufactures one to satisfy the brief has corrupted the round
|
|
88
|
+
in the more expensive direction — a false finding costs a fix unit, an argument, and the credibility
|
|
89
|
+
of the true findings beside it. The adequacy of an all-confirmed round is tested afterwards, against
|
|
90
|
+
the brief, by the orchestrator.
|
|
91
|
+
|
|
92
|
+
## What not to put in a brief
|
|
93
|
+
|
|
94
|
+
- Laws already binding from `AGENTS.md` and the rule files. Reference them; restating invites drift
|
|
95
|
+
between the copy and the original.
|
|
96
|
+
- Any hint of what the other auditor is finding, or has found.
|
|
97
|
+
- Your own hypothesis about where the defect is, beyond what the claims state. An auditor handed a
|
|
98
|
+
suspect investigates the suspect and stops.
|
|
@@ -0,0 +1,148 @@
|
|
|
1
|
+
# Reconciling a round and ruling on it
|
|
2
|
+
|
|
3
|
+
Two auditors return. Neither accepts; the orchestrator does. This is where a round becomes a
|
|
4
|
+
decision, and it is not delegable.
|
|
5
|
+
|
|
6
|
+
## Reproduce before you act
|
|
7
|
+
|
|
8
|
+
The rule beneath this whole section: **run it rather than argue it.** Every judgement below is
|
|
9
|
+
cheap once the probe exists and unreliable until it does.
|
|
10
|
+
|
|
11
|
+
An auditor's finding is a **hypothesis** until the orchestrator has run it. Reproduce every sharp
|
|
12
|
+
claim by hand, against the built output, before it enters a fix brief.
|
|
13
|
+
|
|
14
|
+
**Build the hostile input outside the `try`.** A probe that wraps construction and invocation in one
|
|
15
|
+
catch cannot distinguish _the subject threw_ from _my harness threw_ — a missing import, a wrong
|
|
16
|
+
arity, a `require` in an ESM context all surface as the finding you were hoping to see. Construct
|
|
17
|
+
first, let harness failures crash loudly, and only guard the call under test. Every campaign that has
|
|
18
|
+
run this process has produced at least one finding that was the instrument failing.
|
|
19
|
+
|
|
20
|
+
Reproduction produces three outcomes, and all three matter:
|
|
21
|
+
|
|
22
|
+
- the finding **confirms** and is often **wider** than reported — the reproduction reaches doors the
|
|
23
|
+
auditor did not try;
|
|
24
|
+
- the finding **confirms but is bounded smaller** — real, and not where the auditor thought;
|
|
25
|
+
- the finding **evaporates**, because the auditor's input could not exercise what it claimed to test.
|
|
26
|
+
|
|
27
|
+
The same reproduction discipline applies to your own probes. A probe whose input cannot reach the
|
|
28
|
+
code under test reports a pass that means nothing, and it will read exactly like a real pass.
|
|
29
|
+
|
|
30
|
+
## A disagreement is rarely a tie
|
|
31
|
+
|
|
32
|
+
When two auditors return opposite verdicts on one claim, do not average them and do not prefer the
|
|
33
|
+
engine you trust more. **Reproduce first** — running the disagreement settles most of them outright,
|
|
34
|
+
and it is the only method that can also find what neither auditor saw. Then find the question each
|
|
35
|
+
one answered. The common shapes:
|
|
36
|
+
|
|
37
|
+
- **Both right about different objects.** One tested a case the other did not construct. This is a
|
|
38
|
+
`SPLIT-CLAIM`: the claim was a universal that carried more than one subject. It is **not** a third
|
|
39
|
+
verdict value — one falsifying input makes a universal claim `BROKEN`, and succeeding on a
|
|
40
|
+
different object does not undo that. Split it, keep the original `BROKEN` if any subclaim is
|
|
41
|
+
broken, and carry the split into the successor brief.
|
|
42
|
+
- **Both right about different halves of one claim number.** Same resolution: the claim number was
|
|
43
|
+
carrying two claims. Split and renumber.
|
|
44
|
+
- **One right on the mechanism, the other on the criterion.** Take both. The reconciled ruling is
|
|
45
|
+
frequently neither proposal, and better than either, because each supplied a constraint the other
|
|
46
|
+
violated.
|
|
47
|
+
- **The consequence disproves the premise.** An argument that an input class is unreachable is
|
|
48
|
+
answered by running it and showing what the reachable consequence is.
|
|
49
|
+
|
|
50
|
+
Record which engine was right and on what. A round whose disagreements are smoothed over teaches
|
|
51
|
+
nothing to the next one.
|
|
52
|
+
|
|
53
|
+
## Evidence custody
|
|
54
|
+
|
|
55
|
+
Blind reports are immutable, and their independence is a property of the record, not of anyone's
|
|
56
|
+
memory. A reader six months out must be able to tell an unbiased blind verdict from one produced
|
|
57
|
+
after an auditor saw its counterpart's evidence — otherwise the whole value of running blind is
|
|
58
|
+
unverifiable after the fact.
|
|
59
|
+
|
|
60
|
+
Two rules, both enforceable:
|
|
61
|
+
|
|
62
|
+
1. **A returned verdict is never edited** — not by the auditor, not by the orchestrator.
|
|
63
|
+
2. **Anything an auditor says after seeing another's report is a separate file beside that verdict**,
|
|
64
|
+
under `.orkestrel/<package>/`, named for the unit and the exposure, recording what was shown and
|
|
65
|
+
to whom. It is a durable record, not a journal, so it survives the campaign sweep.
|
|
66
|
+
|
|
67
|
+
That exchange is a **fallback, not a phase.** Reproduction comes first and settles most
|
|
68
|
+
disagreements. Reach for an exchange only when a specific factual question survives reproduction,
|
|
69
|
+
scope it to that question, initiate it yourself, and run it once — a second exchange is negotiation.
|
|
70
|
+
|
|
71
|
+
**Ask the auditor to attack the other's evidence on that question. Never ask it to resolve the
|
|
72
|
+
disagreement, reconsider its position, or say whether the other changed its mind.** Constraining
|
|
73
|
+
when, who, scope and frequency does nothing about convergence if the instruction itself invites it,
|
|
74
|
+
and "does their evidence change your claim?" is the convergence prompt in its purest form.
|
|
75
|
+
|
|
76
|
+
## Bound the finding
|
|
77
|
+
|
|
78
|
+
State what is **not** broken, and why the adjacent behaviour that looks identical is correct. A
|
|
79
|
+
finding without a boundary is an alarm, and alarms get discounted wholesale — including the true
|
|
80
|
+
ones next to them.
|
|
81
|
+
|
|
82
|
+
Two boundaries earn their keep:
|
|
83
|
+
|
|
84
|
+
- **Credit what the round got right.** If the hostile inputs adjacent to the hole are correctly
|
|
85
|
+
contained, say so and list them. It sharpens the finding to a point instead of an area.
|
|
86
|
+
- **Show where the same-looking answer is correct.** When several exports answer a hostile input the
|
|
87
|
+
same way and only one is wrong, name what makes the difference — usually that the correct ones
|
|
88
|
+
agree with a documented view, and the wrong one reads on an axis it then ignores.
|
|
89
|
+
|
|
90
|
+
## Bound the fix before briefing it
|
|
91
|
+
|
|
92
|
+
Establish what over-correcting would break, and put it in the fix brief as a constraint. Both ends
|
|
93
|
+
are usually wrong:
|
|
94
|
+
|
|
95
|
+
- **too little** — a patch to the one function, leaving the package holding two standards for the
|
|
96
|
+
same thing, which is the inconsistency that produced the finding;
|
|
97
|
+
- **too much** — adopting the strictest sibling's rule verbatim, breaking a legitimate caller
|
|
98
|
+
pattern, and tripping "no refusal was widened into a regression" in the next round.
|
|
99
|
+
|
|
100
|
+
Find the rule that fits both. It is usually about **agreement** rather than about categories — what
|
|
101
|
+
a reader reads, its answer must carry — and it dissolves the special cases rather than enumerating
|
|
102
|
+
them.
|
|
103
|
+
|
|
104
|
+
Where the choice is genuinely open, it is a design judgement with a subjective and an objective
|
|
105
|
+
half, and it goes to a blind design pass before code. Ruling it unilaterally is how a fix round
|
|
106
|
+
becomes the next audit's finding.
|
|
107
|
+
|
|
108
|
+
## Certifying an instrument
|
|
109
|
+
|
|
110
|
+
The control-population law in `.claude/rules/quality.md` binds here without restatement. What it
|
|
111
|
+
leaves this round is the procedure.
|
|
112
|
+
|
|
113
|
+
When a round certifies an instrument — a pin, an identity check, a generated sweep — the controls
|
|
114
|
+
are usually drawn from whatever the instrument obviously covers, because that is where the examples
|
|
115
|
+
are easiest to construct. That sampling proves discrimination _within_ the population and is
|
|
116
|
+
routinely reported as proof the instrument works.
|
|
117
|
+
|
|
118
|
+
So before running controls, write down the instrument's **membership rule** in one sentence, then
|
|
119
|
+
ask what the rule excludes. Draw at least one control from there. Two shapes have already cost a
|
|
120
|
+
round each:
|
|
121
|
+
|
|
122
|
+
- an AST comparison whose controls were all drawn from the literal classes present in the bodies it
|
|
123
|
+
guarded, blind to the classes absent from them;
|
|
124
|
+
- a call-closure pin whose controls were all body-reachable functions, green for a function reached
|
|
125
|
+
only through a parameter default.
|
|
126
|
+
|
|
127
|
+
Then write the two sentences that matter: what the controls established, and what they did not. The
|
|
128
|
+
second sentence is the one that gets skipped, and skipping it is how an instrument's credibility
|
|
129
|
+
outruns its evidence.
|
|
130
|
+
|
|
131
|
+
## Ruling
|
|
132
|
+
|
|
133
|
+
- Every retained finding names the fix-brief item that carries it. A finding with no carrier is a
|
|
134
|
+
dropped finding; walk the list once and check.
|
|
135
|
+
- Drop, **on the record**, anything neither auditor can substantiate against the evidence.
|
|
136
|
+
- Promote anything that must outlive the round into a durable artifact before the working files are
|
|
137
|
+
swept. What lives only in a scratch file did not survive.
|
|
138
|
+
- The fix round's auditor is an engine that did not write it.
|
|
139
|
+
- The next round's brief is this round's successor.
|
|
140
|
+
|
|
141
|
+
## The threshold
|
|
142
|
+
|
|
143
|
+
Accept when the brief's claims are **satisfied on evidence** — the `PASS` terminal line the skill
|
|
144
|
+
defines, against a claim set that covers what the subject owns. Not green gates.
|
|
145
|
+
|
|
146
|
+
A round that finds something is the process working. A round that finds nothing because nobody tried
|
|
147
|
+
is the failure; a round re-run because an attack can still be imagined never ends. Bound the claim
|
|
148
|
+
set at the brief, rule on what it returned, and close.
|
|
@@ -41,7 +41,7 @@ Load [hardening.md](references/hardening.md) for the hardening lane and for any
|
|
|
41
41
|
|
|
42
42
|
1. **Bound the campaign.** Record requested outcomes, in-scope environments/domains, explicit exclusions, supported hosts, dirty files, and evidence needed for acceptance.
|
|
43
43
|
2. **Map before editing.** Trace public types, implementations, callers, tests, guides, exports, runtime boundaries, installed Orkestrel dependencies, and applicable legacy/upstream references.
|
|
44
|
-
3. **Establish the intended contract.** Build a capability/defect matrix. Separate verified fact from inference. Mark each row implement, repair, retain, or exclude with a reason.
|
|
44
|
+
3. **Establish the intended contract.** Build a capability/defect matrix. Separate verified fact from inference. Mark each row implement, repair, retain, or exclude with a reason. The matrix is fixed at this step and is the campaign's definition of done: every later step serves a row, and work that serves no row belongs to the next campaign.
|
|
45
45
|
4. **Design types first.** Update guide/spec intent and `*/types.ts` before implementation, under the root design laws. A contract that needs a compatibility shim is the wrong contract.
|
|
46
46
|
5. **Implement completely.** Finish every in-scope branch and reuse the exact installed Orkestrel primitives whose semantics match. The root completion law decides what may not be left behind.
|
|
47
47
|
6. **Prove each defect before repairing it.** A repair begins with a test that fails for that defect: record the exact command and its failing count before the fix and the same command's passing count after. A repair with no red-then-green record is unproven.
|
|
@@ -51,7 +51,7 @@ Load [hardening.md](references/hardening.md) for the hardening lane and for any
|
|
|
51
51
|
10. **Document the final behavior.** Update the governing guide, examples, method tables, limitations, and parity coverage. Document architectural limits honestly.
|
|
52
52
|
11. **Audit completion.** Inspect test discovery, `.todo`/`.skip`/conditional skip use, source/test helper duplication, exports, environment isolation, unexpected text corruption, and the entire diff.
|
|
53
53
|
12. **Verify.** Run the repository-prescribed gates in order and inspect the generated outputs relevant to the request.
|
|
54
|
-
13. **Review independently, and never by the author.** When orchestration is available,
|
|
54
|
+
13. **Review independently, and never by the author.** When orchestration is available, run the two-lane adversarial pass — subjective design fit and objective correctness — plus a mechanical checker, per `.agents/orchestration.md`. Add a dedicated adversarial round for security, concurrency, destructive paths, or external input. A unit's auditor is an engine that did not write it; same-engine re-review returns the author's own blind spot. Resolve every required finding, then rerun affected verification.
|
|
55
55
|
|
|
56
56
|
## Accept the result
|
|
57
57
|
|
|
@@ -63,4 +63,6 @@ Do not accept “mostly complete,” “tests pass” without adequacy review, o
|
|
|
63
63
|
- no unresolved centralization, wrapper, dependency-reuse, test-discovery, lifecycle, security, or text-integrity finding;
|
|
64
64
|
- exact command evidence for every final gate.
|
|
65
65
|
|
|
66
|
+
Completion is those conditions met, not the absence of anything further to find. When every row is closed and the gates are green, stopping is the correct action and the next campaign is the deliverable; a further pass over the same surface is a new instruction from the user, not a finding.
|
|
67
|
+
|
|
66
68
|
Report what changed, what evidence proves it, exact test/gate results, and any genuine residual risk. Do not call an in-scope omission “future work.”
|
|
@@ -10,11 +10,11 @@ inventory, how to classify, and what must be proven before acceptance.
|
|
|
10
10
|
Inspect every touched implementation and centralized file, then sweep the full affected
|
|
11
11
|
environments.
|
|
12
12
|
|
|
13
|
-
| Where | Inventory
|
|
14
|
-
| ------------------- |
|
|
15
|
-
| Implementation file | Interfaces and type aliases, module constants and data, free functions/guards/parsers/factories/schemas, function declarations or assignments inside bodies, extra classes, imports and exports stranded by a move
|
|
16
|
-
| Centralized file | Every module declaration: does it match that file's kind, is it exported, is
|
|
17
|
-
| Environment root | Every declaration promoted there: at least two consuming modules, or it belongs to the owning module's centralized file
|
|
13
|
+
| Where | Inventory |
|
|
14
|
+
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
15
|
+
| Implementation file | Interfaces and type aliases, module constants and data, free functions/guards/parsers/factories/schemas, function declarations or assignments inside bodies, extra classes, imports and exports stranded by a move |
|
|
16
|
+
| Centralized file | Every module declaration: does it match that file's kind, is it exported, is every intentional top-level export reachable from the correct environment barrel regardless of current consumers, does it carry direct behavioral coverage when it carries logic |
|
|
17
|
+
| Environment root | Every declaration promoted there: at least two consuming modules, or it belongs to the owning module's centralized file |
|
|
18
18
|
|
|
19
19
|
The rare runtime-self-contained entrypoint exception must be literally required for
|
|
20
20
|
execution and must explain why sibling imports cannot work.
|
|
@@ -48,6 +48,8 @@ Classify each row:
|
|
|
48
48
|
|
|
49
49
|
“Deferred” is not a final classification for in-scope work.
|
|
50
50
|
|
|
51
|
+
A defect found after its row closed is not in-scope work of this matrix. Record it against the capability it belongs to and carry it into the next matrix — unless it falsifies its row's claim through a path this package itself ships, which makes it this matrix's repair.
|
|
52
|
+
|
|
51
53
|
## Convert evidence into design
|
|
52
54
|
|
|
53
55
|
Before implementation:
|