Menü
Contract integrity preflight — verify the work contract is truthful, consistent, and non-contradictory before reading the diff.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | review/contract |
| description | Contract integrity preflight — verify the work contract is truthful, consistent, and non-contradictory before reading the diff. |
| artifact_class | skill |
| kata_surface | external |
| governing_question | How does β verify that the work contract is truthful, scoped, sourced, and non-contradictory before inspecting implementation? |
| visibility | internal |
| parent | review |
| triggers | ["review contract"] |
| scope | task-local |
| inputs | ["issue","PR body","branch summary"] |
| outputs | ["contract integrity table (yes/no/n/a per check)"] |
| requires | ["review orchestrator loaded"] |
| calls | [] |
GATE: Complete this phase before reading the diff. A branch can be locally well-implemented and still not review-ready if the contract it claims to satisfy is contradictory, stale, or overclaims shipped behavior.
Fill the Contract Integrity table. If any row is "no," the review cannot approve unless the row is explicitly out of scope and the reviewer names why it does not affect merge readiness.
## §2.0.0 Contract Integrity
| Check | Result | Notes |
|---|---|---|
| Status truth preserved | yes / no / n/a | |
| Canonical sources/paths verified | yes / no / n/a | |
| Scope/non-goals consistent | yes / no / n/a | |
| Constraint strata consistent | yes / no / n/a | |
| Exceptions field-specific/reasoned | yes / no / n/a | |
| Path resolution base explicit | yes / no / n/a | |
| Proof shape adequate | yes / no / n/a | |
| Cross-surface projections updated | yes / no / n/a | |
| No witness theater / false closure | yes / no / n/a | |
| PR body matches branch files | yes / no / n/a | |
Verify that the issue, PR body, branch artifacts, and docs distinguish:
Findings:
D if the branch claims runtime enforcement that does not exist.
C if draft/target state is described as current but the diff does not rely on it.
mechanical if the status label is plainly stale across docs/README/source map.
❌ "CTB enforces witnessed close-outs" when only the v0.2 draft defines them.
✅ "CTB v0.2 draft defines witnessed close-outs; ctb-check/runtime enforcement is not shipped."
For every load-bearing claim in the issue or PR body, verify the canonical source. Check:
If paths changed, grep old paths across live docs and code.
docs/alpha/essays/MANIFESTO.md.Check whether any AC, implementation note, PR claim, or output artifact contradicts the non-goals.
Findings:
D if an out-of-scope behavior is implemented or claimed as shipped.
C if the PR body implies out-of-scope work but files do not.
mechanical if the contradiction is textual and deterministic.
❌ Non-goal: "do not implement runtime enforcement." PR body: "runtime now enforces CTB v0.2."
✅ PR body: "adds structural checker issue; runtime enforcement remains out of scope."
If the issue defines required/optional/exception-backed fields or rules, verify that examples and implementation obey the strata. Check:
hard gates are not exception-backed;
exception-backed fields have field-specific exceptions;
optional/defaulted fields name defaults;
validated-if-present fields are actually checked when present;
deferred fields are not silently enforced or claimed.
❌ Hard gate: scope. Exception example: "allowed_missing": ["scope"].
✅ Exception example only lists exception-backed fields such as artifact_class or kata_surface.
Exceptions are debt, not blanket permission. Verify:
exceptions are field-specific;
each exception has a reason;
JSON exceptions do not rely on comments;
exceptions do not exempt hard gates;
cleanup/removal condition is named where appropriate.
❌ { "path": "...", "ignore": true }
✅ { "path": "...", "allowed_missing": ["artifact_class"], "reason": "legacy skill migration pending" }
If the issue or implementation validates paths, verify the resolution base. Check whether paths are:
Require at least one concrete example when path validation is part of the change.
alpha/SKILL.md with calls: design/SKILL.md resolves to src/packages/cnos.cdd/skills/cdd/design/SKILL.md.For checker, schema, parser, runtime, CI, and validation issues, verify that the branch includes:
Existing CI passing is the floor, not the proof.
When the diff adds or changes a status, checker, command, CI job, source map, schema, or runtime surface, verify every projection that should expose it.
Examples:
CI job added → notify aggregation updated.
README source map changed → docs README changed.
Schema added → schema README / fixtures / CI invocation added.
Runtime status changed → help / doctor / status / docs agree.
Upstream formal source added → source map and further-reading sections agree.
❌ Add CI job I5 but leave Telegram/notify aggregation unaware of I5.
✅ I5 is added and notify job result summary includes I5.
If the change adds witnesses, close-outs, review artifacts, checker outputs, debt records, or governance structure, verify that the structure is accountable to evidence. Ask:
Findings:
D if the branch claims enforcement but only adds prose.
C if the structure is useful but lacks the promised rejection mechanism.
B if the rejection mechanism is correctly deferred but the deferral could be clearer.
❌ 10-field close-out shape exists, but no checker or issue says which fields are required.
✅ Spec names required fields; checker issue requires invalid fixtures and diagnostics.
Verify that the PR description still matches the corrected branch files. After fix rounds, PR bodies can describe an older state.
├─ architecture.If all rows are "yes" or "n/a," proceed to Phase 2 (implementation review).
If any row is "no," file findings immediately. The implementation review may still proceed, but verdict must account for the contract-level findings.
Return to orchestrator (review/SKILL.md) → Load Phase 2 starting with review/issue-contract/SKILL.md.
The 0th coherence methodology: how coherence methodologies themselves are measured — this one included. Declares what measuring a CM means per axis, the consistency protocol every CM must pass (an instrument that cannot agree with itself is incoherent as an instrument), the mechanical/LLM split for judging a CM's corpus, and the adversarial-CM doctrine: what follows, mathematically, when one methodology demonstrates that another scores lower. Frontmatter is validated by schemas/skill.cue (#CMOfCMs); the declared signal codes and estimate fields are cross-checked against the engine source and the scoring instruction, exactly as for the 1st methodology.
How TSC measures itself. Declares the full self-measurement procedure — the targets, the deterministic (mechanical) work, and the one narrowly scoped cognitive task delegated to an LLM — and is rendered into the `coh self` command and the tsc-self-measure workflow by scripts/render-self-measure.sh. Frontmatter is validated by schemas/skill.cue (#SelfMeasure); the declared signal codes and estimate fields are cross-checked against the engine source and the scoring instruction, so this declaration cannot silently drift from what runs.
Measurement skill declaring a signal code the engine does not compute (negative fixture for the signal-in-engine cross-check).
Measurement skill declaring an estimate field that appears in the instruction's prose but not in its JSON output contract (negative fixture for the estimate-in-contract exact-set check).
Bootstrap an existing repository to operate under CDD — scaffold, version pin, labels, identity, CI, notifications, secrets, and operator registry.
α role in CDD. Implements the selected change, produces the review-ready artifact set, and writes α close-out.