ai-collab-open-system 0.1.0

package/.aict/mechanisms/root-cause-brake/README.md

@@ -0,0 +1,79 @@
+# Root-Cause Brake
+
+Part of the AI Collaboration Open System. This is a local-first, public-safe mechanism package you can copy into Claude Code, Codex, Cursor, Cline, Windsurf, or Copilot.
+
+## Purpose
+
+Stop a patch-on-patch death spiral by treating repeated rejection as a signal to fix the cause, not the symptom. When the same artifact gets sent back twice in a row, an automatic brake trips: you may NOT ship another patched version. You must first stop and answer four diagnostic questions — is there a contract conflict, is the verification fake, is the scope too big, is the work split wrong — decide the real root cause, and only then write the next version, rebuilt around that cause instead of carrying forward another layer of fixes.
+
+## When to use
+
+Trip the brake the moment the same thing has been rejected twice in a row (two consecutive blocking reviews on the same artifact or task), or whenever you catch yourself about to start version N+1 by adding more fixes to a growing patch list. It also fires on suspicion: a reviewer says 'we keep treating symptoms', or you notice the same kind of defect coming back under a different name each round.
+
+## When not to use
+
+Do not trip it on a first rejection, on rejections of genuinely different things, or on a single small fix that clearly resolves a one-off mistake. One block is normal review; the brake is specifically for the repeated-block pattern. Forcing a full root-cause stop after every minor note is ceremony that buries the signal — the brake only means something if it stays reserved for the second consecutive block on the same target.
+
+## Input shape
+
+The same artifact or task that has now been rejected twice. The findings from each blocking review, kept intact (do not edit the originals — you need the actual pattern across rounds). The version history: which patched versions you produced after each block, so the 'kept adding fixes' pattern is visible. Enough detail on each finding to answer the four diagnostic questions with evidence (which finding, which version, where), not from memory or vibe.
+
+## Input materials
+
+- The twice-rejected artifact or task, named explicitly so the brake is scoped to one target, not a vague 'things keep failing'.
+- Each blocking review's findings, preserved verbatim — the cross-round pattern is the whole diagnostic, and editing the originals destroys it.
+- The version trail: the patched version you shipped after block 1, after block 2, so the patch-on-patch shape is on the record.
+- Per-finding specifics (which finding, which version, what exactly failed) so each of the four questions can be answered with a concrete pointer, not a guess.
+- Any reviewer remark that named a root cause ('this is symptom-chasing'), since that is often the first real diagnosis of why the patches are not landing.
+
+## Process
+
+1. Detect the trip condition: the same artifact has two consecutive blocking reviews. The moment that is true, stop. Do NOT open version N+1 as another patched draft — that move is exactly what the brake forbids.
+2. Answer all four diagnostic questions, each with a yes / no / partly AND concrete evidence (which finding, which version, where it shows). Partial answers are not allowed; a hand-waved 'probably fine' on any question defeats the brake. Q1 Contract conflict: are the agreed definitions — fields, states, interfaces, success criteria — quietly changing from round to round, so each fix breaks a different assumption? Q2 Fake verification: is the checking step (a self-review, a gate, a test) only going through the motions, passing things it should have caught? Q3 Scope too big: is a single unit of work carrying too many fields / states / responsibilities to get right in one pass? Q4 Wrong split: is the work cut too coarse or too fine — a packet that is really five tasks, or a job shattered into pieces that cannot be verified alone?
+3. Name the root cause. From the four answers, state which underlying cause is actually generating the repeat blocks — not a list of surface fixes, but the one structural reason the patches keep failing.
+4. Get the root cause confirmed by the human owner before proceeding (agree / adjust / reject and re-diagnose). The brake is a deliberate governance stop, so the person who owns the work signs off on the diagnosis before the next version starts. This is not a project pause — work resumes immediately after sign-off; it just resumes rebuilt around the cause.
+5. Write version N+1 from the root cause, not from the patch list. The next version is a rebuild aimed at the named cause; it must not re-enact the old defect under a new patch. If the cause was 'scope too big', the next version is smaller; if it was 'fake verification', the next version fixes the check first, and so on.
+6. Record the brake on the record: the preserved findings from each block, the four answered questions with evidence, the named root cause, the owner's decision, and the rebuilt direction — so a later session sees why the chain was broken and does not restart the patch spiral.
+
+## Output shape
+
+- Trip confirmation: a one-line statement that the same target hit two consecutive blocks, so the brake applies.
+- Four answered questions: Q1 contract conflict, Q2 fake verification, Q3 scope too big, Q4 wrong split — each yes/no/partly with a concrete evidence pointer (finding + version + where).
+- Named root cause: the single structural reason the patches kept failing, derived from the four answers.
+- Owner decision: agree / adjust / reject-and-re-diagnose, recorded.
+- Rebuilt direction for version N+1: how the next version is built around the cause, explicitly not a continuation of the patch list.
+- Brake record: preserved per-round findings + answers + cause + decision, so the next session does not reopen the spiral.
+
+## Pass bar (what counts as done / safe to trust)
+
+- The brake actually tripped at the second consecutive block instead of a third patched version going out.
+- All four diagnostic questions are answered with yes/no/partly AND a concrete evidence pointer — none hand-waved.
+- A single structural root cause is named, not a longer list of surface fixes.
+- The human owner confirmed (or adjusted) the root cause before the next version started.
+- Version N+1 is visibly rebuilt around the cause, and the per-round findings are preserved on the record.
+
+## Reject bar (what sends it back)
+
+- A third patched version was shipped after two blocks without ever stopping to diagnose (the patch-on-patch spiral the brake exists to break).
+- One or more of the four questions was skipped or answered 'probably fine' with no evidence, so the brake was ceremony, not a real stop.
+- The 'root cause' is just a restated list of the same surface fixes, so the next version will reproduce the defect.
+- The next version started before the owner signed off on the diagnosis.
+- The original per-round findings were edited or discarded, destroying the cross-round pattern that the diagnosis depends on.
+- The brake was tripped on a first block or on unrelated rejections, draining the signal so a real repeat-block does not stand out.
+
+## Common misuse
+
+- Quietly shipping 'just one more small patch' after the second block because the fix 'feels close', which is precisely the spiral the brake is built to stop.
+- Filling in the four questions as a formality with no evidence, so the diagnostic theatre passes while the real cause stays unfound.
+- Calling a list of surface symptoms the 'root cause', so version N+1 patches the same things again under a new name.
+- Editing the earlier findings to look tidier, which erases the across-rounds pattern that is the entire point of the diagnosis.
+- Tripping the brake on every minor rejection, so the team learns to ignore it and it no longer signals a genuine repeat-block.
+- Treating the brake as a project freeze and stalling the work, when it is only a diagnostic stop — work resumes the moment the owner confirms the cause.
+
+## Package files
+
+- `README.md` explains the mechanism.
+- `PROMPT.md` gives the copy-paste prompt.
+- `TEMPLATE.md` gives the blank operating card.
+- `EXAMPLE.synthetic.md` shows a public-safe run.
+- `FAILURE_MODES.md` names common ways this mechanism fails.

package/.aict/mechanisms/root-cause-brake/TEMPLATE.md

@@ -0,0 +1,74 @@
+# Root-Cause Brake Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Stop a patch-on-patch death spiral by treating repeated rejection as a signal to fix the cause, not the symptom. When the same artifact gets sent back twice in a row, an automatic brake trips: you may NOT ship another patched version. You must first stop and answer four diagnostic questions — is there a contract conflict, is the verification fake, is the scope too big, is the work split wrong — decide the real root cause, and only then write the next version, rebuilt around that cause instead of carrying forward another layer of fixes.
+
+## Template
+
+### Twice-rejected target (name it):
+
+
+### Trip condition met? (two consecutive blocks on this same target — yes/no):
+
+
+### Findings from block 1 (verbatim, do not edit):
+
+
+### Findings from block 2 (verbatim, do not edit):
+
+
+### Patched versions shipped after each block (the patch-on-patch trail):
+
+
+### Q1 Contract conflict? (yes/no/partly + evidence: finding + version + where):
+
+
+### Q2 Fake verification? (yes/no/partly + evidence):
+
+
+### Q3 Scope too big? (yes/no/partly + evidence):
+
+
+### Q4 Wrong split? (yes/no/partly + evidence):
+
+
+### Named root cause (one structural reason, not a fix list):
+
+
+### Owner decision (agree / adjust / reject and re-diagnose):
+
+
+### Version N+1 direction, rebuilt around the cause (NOT another patch):
+
+
+
+## Pass bar (tick before you trust the result)
+
+- The brake actually tripped at the second consecutive block instead of a third patched version going out.
+- All four diagnostic questions are answered with yes/no/partly AND a concrete evidence pointer — none hand-waved.
+- A single structural root cause is named, not a longer list of surface fixes.
+- The human owner confirmed (or adjusted) the root cause before the next version started.
+- Version N+1 is visibly rebuilt around the cause, and the per-round findings are preserved on the record.
+
+## Reject bar (send it back if any of these is true)
+
+- A third patched version was shipped after two blocks without ever stopping to diagnose (the patch-on-patch spiral the brake exists to break).
+- One or more of the four questions was skipped or answered 'probably fine' with no evidence, so the brake was ceremony, not a real stop.
+- The 'root cause' is just a restated list of the same surface fixes, so the next version will reproduce the defect.
+- The next version started before the owner signed off on the diagnosis.
+- The original per-round findings were edited or discarded, destroying the cross-round pattern that the diagnosis depends on.
+- The brake was tripped on a first block or on unrelated rejections, draining the signal so a real repeat-block does not stand out.
+
+## Worked example
+
+See `EXAMPLE.synthetic.md` for this same card filled out end to end on a public-safe synthetic task.
+
+## Completion check
+
+- The mechanism has a named trigger.
+- The next action is concrete.
+- Private details are redacted or rewritten as synthetic examples.
+- The result can be handed to another AI tool without extra chat history.

package/.aict/mechanisms/scout-review-controller/EXAMPLE.synthetic.md

@@ -0,0 +1,15 @@
+# SCOUT Review Controller Synthetic Example
+
+This is a public-safe synthetic example for the AI Collaboration Open System. It is local-first and contains no private account, customer, route, hook, or conversation material.
+
+## Synthetic example
+
+For a synthetic documentation rebuild, Scout lists three structures, Reviewer rejects the marketing-first option, and Controller chooses a runnable workspace-first path.
+
+## How the mechanism changes the outcome
+
+Without this mechanism, a single assistant can produce a smooth answer while hiding uncertainty. With this mechanism, the workflow records trigger, evidence, decision, residual risk, and next action.
+
+## Reuse note
+
+Copy the shape, not the synthetic facts. Adapt the template to your own redacted task.

package/.aict/mechanisms/scout-review-controller/FAILURE_MODES.md

@@ -0,0 +1,16 @@
+# SCOUT Review Controller Failure Modes
+
+AI Collaboration Open System failure checklist. Use it in a local-first workflow before trusting a mechanism run, and rewrite any public example into public-safe language.
+
+## Failure modes
+
+- Scout becomes the decision-maker.
+- Reviewer nitpicks style instead of evidence.
+- Controller keeps every option open and creates no next action.
+
+## Guard questions
+
+1. Did this mechanism change the decision, or just add ceremony?
+2. Is any private material copied instead of summarized or synthesized?
+3. Are blockers, residual risks, and next actions separated?
+4. Could a new session continue from this file alone?

package/.aict/mechanisms/scout-review-controller/PROMPT.md

@@ -0,0 +1,41 @@
+# SCOUT Review Controller Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Separate exploration from decision so the assistant gathers options without prematurely choosing a path.
+
+## Copy-paste prompt
+
+```text
+Use the SCOUT Review Controller mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Separate exploration from decision so the assistant gathers options without prematurely choosing a path.
+
+Trigger:
+Use when the task is ambiguous, cross-tool, or likely to be distorted by the first plausible answer.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Scout collects candidate paths and evidence without deciding.
+2. Reviewer attacks weak assumptions and missing evidence.
+3. Controller selects the smallest path that changes the outcome.
+4. Handoff records rejected paths so the next session does not reopen them by accident.
+
+Return:
+- Decision-changing findings only
+- Evidence used
+- Required fixes
+- Residual risk
+- Next action
+
+Rules:
+- Work from provided material only.
+- Keep private material local.
+- Use public-safe synthetic wording for examples.
+- Label assumptions and unverified claims.
+```

package/.aict/mechanisms/scout-review-controller/README.md

@@ -0,0 +1,30 @@
+# SCOUT Review Controller
+
+Part of the AI Collaboration Open System. This is a local-first, public-safe mechanism package you can copy into Claude Code, Codex, Cursor, Cline, Windsurf, or Copilot.
+
+## Purpose
+
+Separate exploration from decision so the assistant gathers options without prematurely choosing a path.
+
+## When to use
+
+Use when the task is ambiguous, cross-tool, or likely to be distorted by the first plausible answer.
+
+## Input shape
+
+Question, known constraints, candidate paths, evidence sources, and decision deadline.
+
+## Process
+
+1. Scout collects candidate paths and evidence without deciding.
+2. Reviewer attacks weak assumptions and missing evidence.
+3. Controller selects the smallest path that changes the outcome.
+4. Handoff records rejected paths so the next session does not reopen them by accident.
+
+## Package files
+
+- `README.md` explains the mechanism.
+- `PROMPT.md` gives the copy-paste prompt.
+- `TEMPLATE.md` gives the blank operating card.
+- `EXAMPLE.synthetic.md` shows a public-safe run.
+- `FAILURE_MODES.md` names common ways this mechanism fails.

package/.aict/mechanisms/scout-review-controller/TEMPLATE.md

@@ -0,0 +1,38 @@
+# SCOUT Review Controller Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Separate exploration from decision so the assistant gathers options without prematurely choosing a path.
+
+## Template
+
+### Decision question:
+
+
+### Scout evidence:
+
+
+### Candidate paths:
+
+
+### Reviewer objections:
+
+
+### Controller decision:
+
+
+### Rejected paths:
+
+
+### Next verification:
+
+
+
+## Completion check
+
+- The mechanism has a named trigger.
+- The next action is concrete.
+- Private details are redacted or rewritten as synthetic examples.
+- The result can be handed to another AI tool without extra chat history.

package/.aict/mechanisms/single-tool-guard/EXAMPLE.synthetic.md

@@ -0,0 +1,54 @@
+# Single-Tool Guard Synthetic Example
+
+This is a public-safe synthetic example for the AI Collaboration Open System. It is local-first and contains no private account, customer, route, hook, or conversation material.
+
+## Synthetic example
+
+A solo user on one model family gets a confident 'done and tested' claim, opens a fresh conversation, and pastes an adversarial reviewer prompt. The review finds a claimed test that does not exist and ties it to the line. The verdict is recorded as `single-family-only — cross-family binding gate NOT passed`, with the residual risk (a same-family reviewer may share the drafter's blind spots) named on the record.
+
+## Full worked example (filled end to end)
+
+A solo developer has only one model family available. Their execution assistant returned a confident completion claim. Rather than trust the same assistant, they run Single-Tool Guard: a fresh conversation plus an adversarial reviewer prompt, with the verdict explicitly labeled as not-yet-binding.
+
+### Artifact under review (with line/section refs)
+A short completion report plus a code block from the execution assistant. The report says: "Done. I added the CSV export and a test that covers it; everything passes." The code block is pasted with line numbers so the reviewer can cite exact lines.
+
+### Acceptance source / definition of done
+AC1: a button exports the current rows to CSV. AC2: there is an automated test that fails before the change and passes after. AC3: empty-table export produces a header-only file, not a crash. AC4: existing data is untouched.
+
+### Completion claim's evidence (or explicit 'none exists')
+The report asserts 'everything passes' but pastes NO command output and NO test run. Evidence: none provided. That gap is recorded explicitly.
+
+### Single-family acknowledgement
+Only one model family is available. So this is a single-family review from the start, and the verdict will be labeled accordingly — it cannot be a cross-family binding pass.
+
+### Fresh conversation opened?
+Yes. A brand-new conversation is opened; the original drafting thread is NOT reused, because that thread just claimed 'done' and is primed to defend it.
+
+### Adversarial reviewer prompt used
+"You are an adversarial reviewer. Default to refuting this completion claim. Hunt for missing evidence. Tie every finding to a specific line or section. Do not be agreeable; if a claim lacks proof, say so."
+
+### Findings (each cites a line/section)
+- AC2 UNSUPPORTED. The pasted code shows the export function but NO test file and NO test run output. 'Added a test; everything passes' has no evidence behind it at the cited lines.
+- AC3 FAIL. The export maps over the rows with no empty-table branch, so an empty table would write a malformed (or empty) file rather than a header-only file — the cited loop has no guard.
+- AC1 PLAUSIBLE but unverified: the export function is present and looks correct, but with no run output it is asserted, not proven.
+
+### Verdict
+`single-family-only — cross-family binding gate NOT passed`. Reject as a completion claim: AC2 has no evidence and AC3 has a real defect. This is explicitly NOT recorded as a passed dual-guard.
+
+### Residual risk (what a same-family reviewer likely still missed) and who accepted it
+A same-family reviewer shares the drafter's blind spots, so it may have missed an issue a different model family would catch — for example a CSV-escaping bug (commas or quotes inside a cell) that neither the drafter nor this same-family reviewer flagged. The owner accepts this residual risk for now, on the record, pending a cross-family pass.
+
+### Required fixes (re-check in another fresh adversarial pass)
+1. Add the empty-table header-only branch. 2. Add the automated test and paste its fail-then-pass output. Re-review in a new adversarial conversation once both exist.
+
+### Upgrade path
+When a second, different model family becomes available, still run one cross-family binding pass — especially on the CSV-escaping risk a same-family review is most likely to share the blind spot on.
+
+## How the mechanism changes the outcome
+
+Without this mechanism, a single assistant can produce a smooth answer while hiding uncertainty. With this mechanism, the workflow records trigger, evidence, decision, residual risk, and next action.
+
+## Reuse note
+
+Copy the shape, not the synthetic facts. Adapt the template to your own redacted task.

package/.aict/mechanisms/single-tool-guard/FAILURE_MODES.md

@@ -0,0 +1,25 @@
+# Single-Tool Guard Failure Modes
+
+AI Collaboration Open System failure checklist. Use it in a local-first workflow before trusting a mechanism run, and rewrite any public example into public-safe language.
+
+## Failure modes
+
+- The single-family pass is filed as a passed dual-guard, so the next session believes the cross-family binding gate cleared it when it never ran.
+- The drafting thread reviews itself and its eagerness to please buries the objections a fresh adversarial conversation would have surfaced.
+- The residual risk is left unnamed, so the record overstates how much assurance a one-family review actually provides.
+
+## Common misuse (operator errors that look fine but break the mechanism)
+
+- Treating a same-family single review as having passed dual-guard. Same-family reviewers miss the same things; a single-tool pass catches fewer real problems, so it must always be labeled as not-yet-binding, with the residual risk on the record.
+- Skipping the fresh conversation and asking the same thread that just said 'done' to review itself, where its eagerness to please buries the objections.
+- Using a soft 'review this' prompt instead of an adversarial default-to-refute frame, which produces an agreeable rubber stamp rather than findings.
+- Leaving the residual risk blank, so a reader of the record assumes the artifact got more assurance than a single-family pass can give.
+- Reviewing against tone and fluency with no acceptance card or evidence, so the pass grades how it reads instead of whether the claims hold.
+- Treating the single-tool guard as the ceiling and never running the cross-family binding pass even after a second, different model family becomes available.
+
+## Guard questions
+
+1. Did this mechanism change the decision, or just add ceremony?
+2. Is any private material copied instead of summarized or synthesized?
+3. Are blockers, residual risks, and next actions separated?
+4. Could a new session continue from this file alone?

package/.aict/mechanisms/single-tool-guard/PROMPT.md

@@ -0,0 +1,76 @@
+# Single-Tool Guard Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Give a one-model-family user — the realistic default for most solo users, who have exactly one tool — a real guard to START from, not a downgrade to settle for. With a single AI you still turn 'done' into an evidence-backed, re-checkable result. The single-tool guard runs a fresh conversation plus an adversarial reviewer prompt instead of trusting the same assistant that just wrote it. It honestly does NOT equal the cross-family binding gate: it catches fewer real problems, so the verdict is always labeled not-yet-binding, capped at L2, with the residual risk named on the record. The cross-family dual-guard is the upgrade ceiling, not the entry bar.
+
+## Copy-paste prompt
+
+```text
+Use the Single-Tool Guard mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Give a one-model-family user — the realistic default for most solo users, who have exactly one tool — a real guard to START from, not a downgrade to settle for. With a single AI you still turn 'done' into an evidence-backed, re-checkable result. The single-tool guard runs a fresh conversation plus an adversarial reviewer prompt instead of trusting the same assistant that just wrote it. It honestly does NOT equal the cross-family binding gate: it catches fewer real problems, so the verdict is always labeled not-yet-binding, capped at L2, with the residual risk named on the record. The cross-family dual-guard is the upgrade ceiling, not the entry bar.
+
+Trigger:
+This is the default starting point for solo users, who have exactly one tool. Use it at a completion claim when only one model family is available and you would otherwise trust the same assistant that just produced the work: a 'done, tested, shipped' claim, a deliverable about to be handed on, or any output where a wrong 'looks fine' would propagate. It is not a fallback you reach for once a cross-family setup fails — it is where most real work begins, and a single AI here already gives you an evidence-backed, re-checkable result instead of a trusted 'looks fine'.
+
+Do not use when:
+Do not use it as a substitute for a cross-family pass when a second, different model family IS available — in that case run dual-guard, because the cross-family binding gate catches what same-family review cannot. Skip it entirely for low-stakes, easily reversible work a human will fully re-check anyway: a quick fact, a one-line tweak, a throwaway draft. Running an adversarial review on trivial work is ceremony, and ceremony you pay for nothing trains people to skip the review when it actually matters.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Open a NEW conversation. Use a fresh context — the original thread carries the assistant's eagerness to please and its memory of having just claimed done, both of which suppress the very objections you need.
+2. Paste an ADVERSARIAL reviewer prompt: instruct the assistant to default to refuting the work, to hunt for missing evidence rather than confirm, and to tie every finding to a specific line or section. The frame must actually be adversarial, not 'take a look'.
+3. Give it the artifact plus the acceptance card and the completion claim's evidence (or the explicit note that none exists). Ask it to check each completion claim against the evidence, whether the acceptance criteria are met, and whether scope drifted past the stated non-goals.
+4. Mark the verdict explicitly as `single-family-only — cross-family binding gate NOT passed`, and name the residual risk (what a same-family reviewer is most likely to have missed). Never record this as a passed dual-guard.
+5. Resolve each finding one of two ways: fix it and re-show the evidence in another fresh adversarial pass, or carry it explicitly as named residual risk the owner accepts on the record. A silent 'good enough' is not allowed here either.
+6. Upgrade path: when a second, different model family becomes available, still run one cross-family binding pass. The single-tool guard is the floor, not the ceiling.
+
+Output shape:
+- Guard level: this is L2 at best (single tool, author-supplied evidence). It CANNOT reach the cross-family L3 gate, so it cannot return a plain pass.
+- Verdict: one of the four standard states, but bounded by L2 — the strongest a single-tool guard may give is pass_with_risk; it must NOT be recorded as a passed dual-guard. Use reject for a real defect and insufficient_evidence when the completion claim has no evidence at all.
+- Findings, each tied to a specific line or section, produced under an actually-adversarial frame (not a 'looks good' rubber stamp).
+- Residual risk: what a same-family reviewer most likely still missed, named on the record.
+- Owner sign-off: a pass_with_risk is not 'accepted' on the guard's say-so — a human must explicitly accept the named residual risk on the record.
+- Required fixes: the concrete change each blocker needs, to be re-checked in another fresh adversarial pass.
+- Acceptance record: for any finding carried rather than fixed, who accepted the residual risk.
+- Upgrade note: a reminder to run one cross-family binding pass once a second, different model family is available (that is what lifts the ceiling from L2/pass_with_risk to L3/pass).
+
+Return:
+- Decision-changing findings only
+- Evidence used
+- Required fixes
+- Residual risk
+- Next action
+
+Pass bar (do not pass unless all hold):
+- The verdict is at most pass_with_risk (the L2 ceiling) and is NOT recorded as a plain pass or a passed cross-family binding gate.
+- Residual risk is named — what a same-family reviewer most likely still missed is on the record, not left blank.
+- Any pass_with_risk has an explicit owner sign-off on the named residual risk; the guard did not mark it accepted on its own.
+- Every finding is tied to a specific line or section, not a general impression.
+- The adversarial frame was actually used (default-to-refute, hunt-for-missing-evidence), in a fresh conversation, not a 'looks good' rubber stamp from the original thread.
+- The upgrade path is noted: a cross-family binding pass is still owed once a second, different model family is available (that is what lifts the ceiling to L3/pass).
+
+Reject bar (send back if any holds):
+- The single-family review is recorded as a plain pass or as if it cleared the binding gate (the head failure — a same-family pass dressed up as dual-guard / L3).
+- A pass_with_risk is treated as accepted without an explicit owner sign-off on the residual risk.
+- No residual risk is named, so the next session inherits a hidden gap and assumes more assurance than the pass actually provides.
+- The reviewer only graded tone, fluency, or style instead of checking claims against evidence.
+- The drafting thread was reused instead of a fresh conversation, so the assistant's just-claimed-done eagerness suppressed the objections.
+- The frame was not adversarial — it was a 'take a look' that produced an agreeable 'seems fine'.
+
+Rules:
+- Work from provided material only.
+- Keep private material local.
+- Use public-safe synthetic wording for examples.
+- Label assumptions and unverified claims.
+```
+
+## Full worked example
+
+See `EXAMPLE.synthetic.md` for this prompt run from start to finish on a public-safe synthetic task.

package/.aict/mechanisms/single-tool-guard/README.md

@@ -0,0 +1,83 @@
+# Single-Tool Guard
+
+Part of the AI Collaboration Open System. This is a local-first, public-safe mechanism package you can copy into Claude Code, Codex, Cursor, Cline, Windsurf, or Copilot.
+
+## Purpose
+
+Give a one-model-family user — the realistic default for most solo users, who have exactly one tool — a real guard to START from, not a downgrade to settle for. With a single AI you still turn 'done' into an evidence-backed, re-checkable result. The single-tool guard runs a fresh conversation plus an adversarial reviewer prompt instead of trusting the same assistant that just wrote it. It honestly does NOT equal the cross-family binding gate: it catches fewer real problems, so the verdict is always labeled not-yet-binding, capped at L2, with the residual risk named on the record. The cross-family dual-guard is the upgrade ceiling, not the entry bar.
+
+## When to use
+
+This is the default starting point for solo users, who have exactly one tool. Use it at a completion claim when only one model family is available and you would otherwise trust the same assistant that just produced the work: a 'done, tested, shipped' claim, a deliverable about to be handed on, or any output where a wrong 'looks fine' would propagate. It is not a fallback you reach for once a cross-family setup fails — it is where most real work begins, and a single AI here already gives you an evidence-backed, re-checkable result instead of a trusted 'looks fine'.
+
+## When not to use
+
+Do not use it as a substitute for a cross-family pass when a second, different model family IS available — in that case run dual-guard, because the cross-family binding gate catches what same-family review cannot. Skip it entirely for low-stakes, easily reversible work a human will fully re-check anyway: a quick fact, a one-line tweak, a throwaway draft. Running an adversarial review on trivial work is ceremony, and ceremony you pay for nothing trains people to skip the review when it actually matters.
+
+## Input shape
+
+The artifact under review, with stable line or section references the reviewer can point to. The acceptance card or definition of done it claims to meet. The completion claim's evidence — command output, test results, a reproduced result — or an explicit note that none exists. The context boundary (goal, scope, non-goals) so the reviewer can catch scope drift. A clear acknowledgement that only one model family is available, which is why this is a single-family review and not a cross-family binding pass.
+
+## Input materials
+
+- Artifact under review, with line numbers or section anchors so a finding cites an exact spot, not a vibe.
+- Acceptance card / definition of done: the checkable criteria the artifact claims to satisfy.
+- Completion-claim evidence: the actual command output, test result, or reproduced behavior the claim rests on, or an explicit note that none exists.
+- Context boundary: goal, in-scope, and explicit non-goals, so the reviewer can catch scope drift.
+- Single-family acknowledgement: a stated note that only one model family is available, so the verdict is framed as not-yet-binding from the start.
+- The original drafting thread is deliberately NOT reused: a fresh conversation is opened, because the original thread carries the assistant's eagerness to please and its memory of having just claimed done.
+
+## Process
+
+1. Open a NEW conversation. Use a fresh context — the original thread carries the assistant's eagerness to please and its memory of having just claimed done, both of which suppress the very objections you need.
+2. Paste an ADVERSARIAL reviewer prompt: instruct the assistant to default to refuting the work, to hunt for missing evidence rather than confirm, and to tie every finding to a specific line or section. The frame must actually be adversarial, not 'take a look'.
+3. Give it the artifact plus the acceptance card and the completion claim's evidence (or the explicit note that none exists). Ask it to check each completion claim against the evidence, whether the acceptance criteria are met, and whether scope drifted past the stated non-goals.
+4. Mark the verdict explicitly as `single-family-only — cross-family binding gate NOT passed`, and name the residual risk (what a same-family reviewer is most likely to have missed). Never record this as a passed dual-guard.
+5. Resolve each finding one of two ways: fix it and re-show the evidence in another fresh adversarial pass, or carry it explicitly as named residual risk the owner accepts on the record. A silent 'good enough' is not allowed here either.
+6. Upgrade path: when a second, different model family becomes available, still run one cross-family binding pass. The single-tool guard is the floor, not the ceiling.
+
+## Output shape
+
+- Guard level: this is L2 at best (single tool, author-supplied evidence). It CANNOT reach the cross-family L3 gate, so it cannot return a plain pass.
+- Verdict: one of the four standard states, but bounded by L2 — the strongest a single-tool guard may give is pass_with_risk; it must NOT be recorded as a passed dual-guard. Use reject for a real defect and insufficient_evidence when the completion claim has no evidence at all.
+- Findings, each tied to a specific line or section, produced under an actually-adversarial frame (not a 'looks good' rubber stamp).
+- Residual risk: what a same-family reviewer most likely still missed, named on the record.
+- Owner sign-off: a pass_with_risk is not 'accepted' on the guard's say-so — a human must explicitly accept the named residual risk on the record.
+- Required fixes: the concrete change each blocker needs, to be re-checked in another fresh adversarial pass.
+- Acceptance record: for any finding carried rather than fixed, who accepted the residual risk.
+- Upgrade note: a reminder to run one cross-family binding pass once a second, different model family is available (that is what lifts the ceiling from L2/pass_with_risk to L3/pass).
+
+## Pass bar (what counts as done / safe to trust)
+
+- The verdict is at most pass_with_risk (the L2 ceiling) and is NOT recorded as a plain pass or a passed cross-family binding gate.
+- Residual risk is named — what a same-family reviewer most likely still missed is on the record, not left blank.
+- Any pass_with_risk has an explicit owner sign-off on the named residual risk; the guard did not mark it accepted on its own.
+- Every finding is tied to a specific line or section, not a general impression.
+- The adversarial frame was actually used (default-to-refute, hunt-for-missing-evidence), in a fresh conversation, not a 'looks good' rubber stamp from the original thread.
+- The upgrade path is noted: a cross-family binding pass is still owed once a second, different model family is available (that is what lifts the ceiling to L3/pass).
+
+## Reject bar (what sends it back)
+
+- The single-family review is recorded as a plain pass or as if it cleared the binding gate (the head failure — a same-family pass dressed up as dual-guard / L3).
+- A pass_with_risk is treated as accepted without an explicit owner sign-off on the residual risk.
+- No residual risk is named, so the next session inherits a hidden gap and assumes more assurance than the pass actually provides.
+- The reviewer only graded tone, fluency, or style instead of checking claims against evidence.
+- The drafting thread was reused instead of a fresh conversation, so the assistant's just-claimed-done eagerness suppressed the objections.
+- The frame was not adversarial — it was a 'take a look' that produced an agreeable 'seems fine'.
+
+## Common misuse
+
+- Treating a same-family single review as having passed dual-guard. Same-family reviewers miss the same things; a single-tool pass catches fewer real problems, so it must always be labeled as not-yet-binding, with the residual risk on the record.
+- Skipping the fresh conversation and asking the same thread that just said 'done' to review itself, where its eagerness to please buries the objections.
+- Using a soft 'review this' prompt instead of an adversarial default-to-refute frame, which produces an agreeable rubber stamp rather than findings.
+- Leaving the residual risk blank, so a reader of the record assumes the artifact got more assurance than a single-family pass can give.
+- Reviewing against tone and fluency with no acceptance card or evidence, so the pass grades how it reads instead of whether the claims hold.
+- Treating the single-tool guard as the ceiling and never running the cross-family binding pass even after a second, different model family becomes available.
+
+## Package files
+
+- `README.md` explains the mechanism.
+- `PROMPT.md` gives the copy-paste prompt.
+- `TEMPLATE.md` gives the blank operating card.
+- `EXAMPLE.synthetic.md` shows a public-safe run.
+- `FAILURE_MODES.md` names common ways this mechanism fails.

package/.aict/mechanisms/single-tool-guard/TEMPLATE.md

@@ -0,0 +1,75 @@
+# Single-Tool Guard Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Give a one-model-family user — the realistic default for most solo users, who have exactly one tool — a real guard to START from, not a downgrade to settle for. With a single AI you still turn 'done' into an evidence-backed, re-checkable result. The single-tool guard runs a fresh conversation plus an adversarial reviewer prompt instead of trusting the same assistant that just wrote it. It honestly does NOT equal the cross-family binding gate: it catches fewer real problems, so the verdict is always labeled not-yet-binding, capped at L2, with the residual risk named on the record. The cross-family dual-guard is the upgrade ceiling, not the entry bar.
+
+## Template
+
+### Artifact under review (with line/section refs):
+
+
+### Acceptance source / definition of done:
+
+
+### Completion claim's evidence (or explicit 'none exists'):
+
+
+### Single-family acknowledgement (only one model family available):
+
+
+### Fresh conversation opened? (must be yes — do not reuse the drafting thread):
+
+
+### Adversarial reviewer prompt used (default to refute, hunt missing evidence, cite specific spots):
+
+
+### Findings (each cites a line/section/missing evidence):
+
+
+### Guard level reached — L2 at most (single tool); a clean pass would need the cross-family L3 pack:
+
+
+### Verdict — pass_with_risk / reject / insufficient_evidence (NEVER a plain pass; NEVER recorded as a passed dual-guard):
+
+
+### Residual risk (what a same-family reviewer likely still missed) and who accepted it (a pass_with_risk needs an explicit owner sign-off):
+
+
+### Required fixes (re-check in another fresh adversarial pass):
+
+
+### Upgrade path (run a cross-family binding pass when a second family is available):
+
+
+
+## Pass bar (tick before you trust the result)
+
+- The verdict is at most pass_with_risk (the L2 ceiling) and is NOT recorded as a plain pass or a passed cross-family binding gate.
+- Residual risk is named — what a same-family reviewer most likely still missed is on the record, not left blank.
+- Any pass_with_risk has an explicit owner sign-off on the named residual risk; the guard did not mark it accepted on its own.
+- Every finding is tied to a specific line or section, not a general impression.
+- The adversarial frame was actually used (default-to-refute, hunt-for-missing-evidence), in a fresh conversation, not a 'looks good' rubber stamp from the original thread.
+- The upgrade path is noted: a cross-family binding pass is still owed once a second, different model family is available (that is what lifts the ceiling to L3/pass).
+
+## Reject bar (send it back if any of these is true)
+
+- The single-family review is recorded as a plain pass or as if it cleared the binding gate (the head failure — a same-family pass dressed up as dual-guard / L3).
+- A pass_with_risk is treated as accepted without an explicit owner sign-off on the residual risk.
+- No residual risk is named, so the next session inherits a hidden gap and assumes more assurance than the pass actually provides.
+- The reviewer only graded tone, fluency, or style instead of checking claims against evidence.
+- The drafting thread was reused instead of a fresh conversation, so the assistant's just-claimed-done eagerness suppressed the objections.
+- The frame was not adversarial — it was a 'take a look' that produced an agreeable 'seems fine'.
+
+## Worked example
+
+See `EXAMPLE.synthetic.md` for this same card filled out end to end on a public-safe synthetic task.
+
+## Completion check
+
+- The mechanism has a named trigger.
+- The next action is concrete.
+- Private details are redacted or rewritten as synthetic examples.
+- The result can be handed to another AI tool without extra chat history.