ai-collab-open-system 0.1.0

package/.aict/mechanisms/collaboration-coach/README.md

@@ -0,0 +1,79 @@
+# Collaboration Coach
+
+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
+
+Make the assistant proactively remind the user of the matching collaboration step at six recurring moments — define done, review a completion claim, hand off, harvest, update the profile — instead of waiting to be asked, so the workspace teaches itself while the user works rather than sitting unused behind a manual. The hard constraint is restraint: prompt at key moments only, once per moment, never every turn, because over-prompting is the fastest way to get the whole system uninstalled.
+
+## When to use
+
+Run it as a standing behavior the moment a collaboration moment fires: a new task or vague idea arrives, the assistant is about to act before 'done' is defined, it just claimed completion, the thread is getting long or work is moving to another tool, a reusable judgment or lesson surfaced, or the same preference has shown up several times. The point is that the assistant raises the matching step on its own at that moment, not three turns later when the user finally remembers to ask.
+
+## When not to use
+
+Do not prompt on low-stakes, fast-turn work: a quick fact lookup, a one-line edit, a yes/no confirmation, a casual exchange, or any moment where the user clearly just wants the answer. Do not re-fire a reminder the user already acted on or explicitly waved off. A reminder on trivial work is noise, and noise on every turn trains the user to mute the coach exactly when a real high-stakes moment arrives — so the failure here is not 'missed a prompt', it is 'prompted so often the user turned it off'.
+
+## Input shape
+
+The live collaboration moment (which of the six nodes is firing, and the signal that tripped it). The current restraint tier (light / standard / strict), defaulting to standard. Whether this exact reminder has already fired or been dismissed in this thread, so it is not repeated. For the completion-claim node: how many model families are available, so the right guard depth is named (one family -> single-tool-guard; a second different family -> dual-guard; multi-tool -> full fusion review). The matching concrete next action for whichever node fired, so the prompt hands the user a step, not a lecture.
+
+## Input materials
+
+- The firing node (1 task start, 2 pre-execution, 3 completion claim, 4 long thread / tool switch, 5 reusable insight, 6 repeated preference) and the signal that tripped it.
+- Restraint tier: light (nodes 3 and 4 only), standard (default — fire at nodes 1, 3, 4, 6; fold node 2 into the task-start reminder and node 5 into a natural pause; count once-per-moment by task phase not by node), or strict (all six, every time they fire); default standard.
+- Already-fired / dismissed memory for this thread, so a reminder is not repeated after the user has acted on it or waved it off.
+- Model-family count at the completion-claim node, so the guard depth is named correctly (one -> single-tool-guard, two different -> dual-guard, multi-tool -> full fusion).
+- The concrete next action attached to the firing node, so the prompt offers a step (write the acceptance card, open single-tool-guard, write the handoff) rather than an abstract nudge.
+- User restraint command, if any (`coach: light` / `coach: standard` / `coach: strict`), which changes how often the coach speaks up.
+
+## Process
+
+1. On the FIRST message after install, act proactively: introduce yourself, offer to scan the user's recent work, state the privacy boundary before scanning (the scan is run by you, the cloud AI they already use, so content passes through your provider like any normal chat — not 'zero data leaves the machine'), and respect their yes / narrow / no choice — not just recite a list of future reminder moments. Then say reminders are restrained by default and switchable with `coach: light` / `coach: strict`. Do this once, then stop.
+2. Map each firing moment to its node and reminder. 1 Task start -> set a context boundary and acceptance before building. 2 Pre-execution -> define the acceptance card first. 3 Completion claim -> run a guard review before trusting it. 4 Long thread / tool switch -> generate a handoff instead of relying on chat memory. 5 Reusable insight -> harvest it into a card. 6 Repeated preference -> offer it as a profile-update candidate.
+3. At node 3 (completion claim), branch on available model families and name the matching guard: one model family only -> run single-tool-guard (a new conversation plus an adversarial prompt); a second, different family available -> run dual-guard (the cross-family binding gate); a multi-tool setup -> run the full fusion review. Do not silently skip the branch and just say 'looks good'.
+4. Apply the restraint tier before speaking. Light: only fire at nodes 3 and 4. Standard (default): fire at nodes 1, 3, 4, 6 — fold node 2 into the task-start reminder (skip it entirely if node 1 already landed an acceptance card) and node 5 into a natural pause, not a separate interruption; count "once per moment" by task phase, not by node, so the opening of one task is a single moment even if nodes 1 and 2 both trip — never stack reminders on back-to-back turns at a task's start, and never re-raise a reminder already acted on. Strict: fire at all six every time they trip. If a tier would make you repeat a just-given reminder, stay silent instead.
+5. Keep each reminder to one or two sentences that hand over the concrete next step, then continue the actual work. Do not pause to explain the philosophy of the layer, do not stack multiple reminders into a wall, and do not lecture — a prompt the user cannot act on in one move is noise.
+6. Honor a restraint switch immediately. When the user says `coach: light` / `coach: standard` / `coach: strict`, change tier for the rest of the session without arguing, and confirm the new tier in a few words.
+
+## Output shape
+
+- First-run promise: on the first reply, the assistant proactively introduces itself, offers to scan the user's recent work, states the privacy boundary before scanning, and respects the user's yes / narrow / no choice — rather than passively reciting a list of future reminder moments.
+- Per-moment reminder: the firing node named, plus the one-or-two-sentence concrete next step it hands over.
+- Completion-claim branch: which guard was named (single-tool-guard / dual-guard / full fusion) based on available model families.
+- Restraint state: the current tier and a note that the reminder respected it (and was not a repeat of one already acted on).
+- Tier change acknowledgement: when the user switches, the new tier confirmed in a few words.
+- Continuation: the reminder is followed by getting on with the actual task, not by a paragraph of theory.
+
+## Pass bar (what counts as done / safe to trust)
+
+- On the first reply the assistant acted proactively: it introduced itself, offered to scan recent work, stated the privacy boundary before scanning, respected the user's yes / narrow / no choice, and did not repeat the intro afterward.
+- Each reminder fired at the right node with a concrete next step the user can act on in one move.
+- The completion-claim node named the correct guard depth for the number of model families available.
+- Restraint held: standard by default, once per moment, no reminder the user already acted on was re-raised, and a `coach:` switch was honored immediately.
+- Reminders stayed short and the assistant got back to the work instead of lecturing about the layer.
+
+## Reject bar (what sends it back)
+
+- A reminder fires every turn, or the same reminder is repeated after the user already acted on it (over-prompting — the uninstall path).
+- The completion-claim node says 'looks good' or skips the guard branch instead of naming single-tool-guard / dual-guard / full fusion.
+- A reminder hands over a lecture or a vague nudge instead of a concrete next step.
+- The default silently runs at strict (all six, every time) when the user never asked for it, burying the signal.
+- A `coach:` restraint switch is ignored or argued with instead of applied for the rest of the session.
+
+## Common misuse
+
+- Turning every turn into a reminder so the user mutes the coach — the most common way this mechanism gets the whole system uninstalled, and the exact opposite of thoroughness.
+- Naming a step but not the action: 'you should probably guard this' with no pointer to single-tool-guard or dual-guard, so the user is reminded but not moved.
+- Skipping the completion-claim branch and rubber-stamping 'done' as 'looks good', which is the one node that exists to stop a fluent false completion.
+- Lecturing the theory of the coaching layer mid-task instead of handing over one concrete step and continuing.
+- Defaulting to strict (or to silent) instead of standard, so the user either drowns in prompts or never gets the reminder that mattered.
+- Re-firing a reminder the user already dismissed, which reads as nagging and trains them to ignore the next one.
+
+## 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/collaboration-coach/TEMPLATE.md

@@ -0,0 +1,61 @@
+# Collaboration Coach Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Make the assistant proactively remind the user of the matching collaboration step at six recurring moments — define done, review a completion claim, hand off, harvest, update the profile — instead of waiting to be asked, so the workspace teaches itself while the user works rather than sitting unused behind a manual. The hard constraint is restraint: prompt at key moments only, once per moment, never every turn, because over-prompting is the fastest way to get the whole system uninstalled.
+
+## Template
+
+### First-run promise (first reply, proactive — introduce + offer to scan + state the privacy boundary + respect yes / narrow / no):
+
+
+### Firing node (1-6) and the signal that tripped it:
+
+
+### Restraint tier in effect (light / standard / strict; default standard):
+
+
+### Already fired or dismissed this thread? (if yes, stay silent):
+
+
+### Matching reminder (one or two sentences, hands over the concrete next step):
+
+
+### Completion-claim branch (one family -> single-tool-guard / two different -> dual-guard / multi-tool -> full fusion):
+
+
+### Tier change to acknowledge (if the user said coach: light / standard / strict):
+
+
+### Continue the actual task:
+
+
+
+## Pass bar (tick before you trust the result)
+
+- On the first reply the assistant acted proactively: it introduced itself, offered to scan recent work, stated the privacy boundary before scanning, respected the user's yes / narrow / no choice, and did not repeat the intro afterward.
+- Each reminder fired at the right node with a concrete next step the user can act on in one move.
+- The completion-claim node named the correct guard depth for the number of model families available.
+- Restraint held: standard by default, once per moment, no reminder the user already acted on was re-raised, and a `coach:` switch was honored immediately.
+- Reminders stayed short and the assistant got back to the work instead of lecturing about the layer.
+
+## Reject bar (send it back if any of these is true)
+
+- A reminder fires every turn, or the same reminder is repeated after the user already acted on it (over-prompting — the uninstall path).
+- The completion-claim node says 'looks good' or skips the guard branch instead of naming single-tool-guard / dual-guard / full fusion.
+- A reminder hands over a lecture or a vague nudge instead of a concrete next step.
+- The default silently runs at strict (all six, every time) when the user never asked for it, burying the signal.
+- A `coach:` restraint switch is ignored or argued with instead of applied for the rest of the session.
+
+## 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/do-not-handle-yet/EXAMPLE.synthetic.md

@@ -0,0 +1,15 @@
+# Do Not Handle Yet 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
+
+During CLI init work, visual branding polish is parked until init, demo, check, privacy scan, and package dry-run are green.
+
+## 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/do-not-handle-yet/FAILURE_MODES.md

@@ -0,0 +1,16 @@
+# Do Not Handle Yet 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
+
+- Parking becomes deletion because no revisit condition exists.
+- The assistant handles the parked item anyway.
+- The parking note hides a true blocker.
+
+## 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/do-not-handle-yet/PROMPT.md

@@ -0,0 +1,41 @@
+# Do Not Handle Yet Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Protect the main line by explicitly parking tempting but lower-priority work.
+
+## Copy-paste prompt
+
+```text
+Use the Do Not Handle Yet mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Protect the main line by explicitly parking tempting but lower-priority work.
+
+Trigger:
+Use when a task reveals adjacent bugs, polish ideas, product questions, or architecture tangents.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Name the current slice and completion standard.
+2. Write the adjacent item in a parking note.
+3. Explain why handling it now would harm the main line.
+4. Define when to revisit it.
+
+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/do-not-handle-yet/README.md

@@ -0,0 +1,30 @@
+# Do Not Handle Yet
+
+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
+
+Protect the main line by explicitly parking tempting but lower-priority work.
+
+## When to use
+
+Use when a task reveals adjacent bugs, polish ideas, product questions, or architecture tangents.
+
+## Input shape
+
+Main goal, current slice, tempting adjacent item, risk if handled now, and revisit condition.
+
+## Process
+
+1. Name the current slice and completion standard.
+2. Write the adjacent item in a parking note.
+3. Explain why handling it now would harm the main line.
+4. Define when to revisit it.
+
+## 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/do-not-handle-yet/TEMPLATE.md

@@ -0,0 +1,38 @@
+# Do Not Handle Yet Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Protect the main line by explicitly parking tempting but lower-priority work.
+
+## Template
+
+### Current slice:
+
+
+### Parked item:
+
+
+### Reason not now:
+
+
+### Risk if handled now:
+
+
+### Revisit condition:
+
+
+### Owner decision needed:
+
+
+### Storage target:
+
+
+
+## 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/dual-guard/EXAMPLE.synthetic.md

@@ -0,0 +1,54 @@
+# Dual 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 synthetic release note passes product clarity but the cross-family binding guard blocks it because the text claims a smoke test that did not run. By layered strictness the merged result is reject until the command output exists.
+
+## Full worked example (filled end to end)
+
+An execution AI was asked to add a feature to a small synthetic task board and report when it was done. It returned a confident 'done, implemented and tested' message. The owner runs Dual Guard before trusting that claim.
+
+### Artifact under review
+A short completion report plus a code block from the execution AI (call it the drafter, from model family X). The report says: "Done. I implemented the new task-reordering feature with both mouse drag and keyboard arrow-key support, and I added tests; everything passes." The code block is given with line numbers so a guard can cite exact lines.
+
+### Acceptance source / definition of done
+AC1: a task can be reordered with the mouse. AC2: a task can be reordered with the keyboard arrow keys (accessibility requirement). AC3: both paths have an automated test that fails before the change and passes after. AC4: existing task data survives. AC5: visual restyling is out of scope and must be reported as unverified, not done.
+
+### Drafting model family
+Family X (the same assistant that wrote the code). So the binding guard must come from a different family, Family Y.
+
+### Binding guard (different family) findings
+The Family-Y guard reads the code against the acceptance card and reports, each tied to a line:
+- AC2 FAIL. The keyboard handler at the cited lines only logs the key press and never calls the reorder function, so arrow keys move nothing. The completion claim says keyboard reordering 'is supported' — the code does not back that claim.
+- AC3 FAIL. There is one test, and it only covers the mouse path. There is no keyboard test, so 'I added tests; everything passes' overstates the evidence.
+- AC1 PASS with evidence: the mouse path calls the reorder function and the single test exercises it.
+- AC4 PASS: the reorder operates on the existing data shape; no migration.
+- Verdict from the binding guard: reject. The claim asserts more than the code and tests prove.
+
+### Reference guard (same family) focus and findings (advisory only)
+A second Family-X guard is run for an extra angle. It agrees the keyboard path looks thin and adds one advisory note: even once arrow keys work, focus has to land on the right item first, so a focus-order check would be worth adding later. This is recorded as advisory input — it does not clear or block the gate by itself.
+
+### Merge rule = layered strictness
+Not a vote. The drafter said 'done', and a reader skimming the fluent report might have accepted it. But the cross-family binding guard pointed to two concrete, evidence-grounded blockers (AC2 and AC3). One real blocker is enough; two settle it. The reference guard's agreement is consistent but is not what decides the verdict.
+
+### Verdict
+Reject (blocker: keyboard reorder is claimed but neither implemented nor tested).
+
+### Required fixes
+1. Make the keyboard handler call the reorder function for ArrowUp / ArrowDown. 2. Add a keyboard reorder test that fails against the current stub and passes after the fix. 3. Either implement AC2/AC3 or move keyboard support out of scope explicitly and correct the completion claim to match — do not leave the claim broader than the code.
+
+### Residual risk and who accepted it
+Visual restyling (AC5) stays out of scope and is carried as named residual risk, accepted by the owner for this slice. The advisory focus-order check is logged for a future pass, not blocking now.
+
+### Next action
+Send the two required fixes back to the drafter. Re-run only the binding (cross-family) guard on the revised output; it clears the gate once the keyboard test fails-then-passes and the claim matches the code. Then the result can be trusted by the next session.
+
+## 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/dual-guard/FAILURE_MODES.md

@@ -0,0 +1,25 @@
+# Dual 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
+
+- Both guards review the same surface and miss the real risk.
+- The controller copies every comment instead of merging decision-changing findings.
+- A warning is treated as a pass without naming residual risk.
+
+## Common misuse (operator errors that look fine but break the mechanism)
+
+- Treating it as a vote: two approvals and one blocker get tallied as 'pass'. It is not a poll; one concrete, evidence-grounded blocker is enough to reject.
+- Using two guards from the SAME model family and calling it dual-guard. Same-family reviewers tend to miss the same things; same-family passes catch fewer real problems than a cross-family pass, so without the cross-family binding guard the structure's whole point is gone.
+- Letting the binding guard 'review' with no acceptance card or evidence, so it grades tone and fluency instead of checking claims against proof.
+- Copying every comment from both guards into the merge instead of keeping only the decision-changing findings, which buries the real blocker in noise.
+- Accepting a warning as a pass without writing down the residual risk or who accepted it, so the next session inherits a hidden gap.
+- Skipping the whole mechanism on a genuinely high-stakes artifact because it 'reads fine' which is exactly the fluent-but-wrong case the cross-family guard exists to catch.
+
+## 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/dual-guard/PROMPT.md

@@ -0,0 +1,76 @@
+# Dual 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
+
+Cancel shared blind spots with structure instead of a stronger model: a guard from a different model family is the binding gate, and a same-family guard is a non-binding reference, so a fluent answer cannot be trusted just because it reads well.
+
+Don't have a second model family yet? See the cookbook recipe `../../cookbook/bridge-to-a-second-family.md` for how to set one up (manual copy-paste or an optional auto bridge) and route this review across it. The `[paste ... here]` slot below assumes you already have that second, different-family AI to paste into.
+
+## Copy-paste prompt
+
+```text
+Use the Dual Guard mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Cancel shared blind spots with structure instead of a stronger model: a guard from a different model family is the binding gate, and a same-family guard is a non-binding reference, so a fluent answer cannot be trusted just because it reads well.
+
+Trigger:
+Use before you trust an artifact that another session, another tool, or another person will build on: a release candidate, a public document, a high-risk plan, a completion claim that says work is done, or any output where a wrong 'looks fine' would propagate.
+
+Do not use when:
+Skip it for low-stakes, easily reversible, or already-verified work: a quick fact lookup, a one-line wording tweak, a throwaway scratch draft, or a step a human is about to fully re-check anyway. Running the full two-layer review on trivial work is pure ceremony cost, 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. Pick a binding guard from a DIFFERENT model family than the one that drafted the artifact. It does not share the drafter's context window, recent training nudges, or eagerness to please, so it is the pass most likely to see a problem the author cannot. This is the hard gate.
+2. Give the binding guard the artifact plus acceptance card, context boundary, and the evidence list. Ask it to check, in order: does each completion claim have evidence that actually backs it; does the work meet the acceptance criteria; did scope drift past the stated non-goals; is anything private leaking; what is asserted but unproven. Require every finding to point to a specific line, section, or missing piece of evidence.
+3. Optionally run a same-family guard as a REFERENCE pass for a second angle (style, an alternate user path, a missed edge case). Treat its output as input only: it never substitutes for the cross-family pass and never alone clears the gate.
+4. Merge by layered strictness, not by majority vote. This is not a poll. If ANY guard names a real, evidence-grounded blocker, the artifact does not pass, even if the other guard liked it. One concrete defect outweighs two fluent approvals.
+5. Resolve each blocker one of two ways: fix it and re-show the evidence, or carry it explicitly as named residual risk that the human owner accepts on the record. Silent 'good enough' is not allowed.
+6. Record the outcome so a later session can trust it without re-litigating: what was reviewed, which guard was binding vs reference, the findings, the fixes, the residual risk, and the next action.
+
+Output shape:
+- Verdict: one of the four standard states — pass / reject / insufficient_evidence / pass_with_risk.
+- Guard level: this is the L3 path (a structured evidence pack reviewed by a different model family), so it can return pass; an L4 pass additionally requires the binding guard to have independently re-run the key evidence and shown that rerun output.
+- Binding guard (cross-family) findings: each tied to a line, section, or missing evidence.
+- Reference guard (same-family) findings: labeled as advisory, not gate-clearing.
+- Merge decision: which findings were decision-changing and why the verdict follows from layered strictness.
+- Required fixes: the concrete change each blocker needs.
+- Residual risk: what stays unverified and who accepted it (a pass_with_risk needs an explicit owner sign-off, not the guard's own say-so).
+- Next action: the exact next step (re-review after fix, hand off, or release).
+
+Return:
+- Decision-changing findings only
+- Evidence used
+- Required fixes
+- Residual risk
+- Next action
+
+Pass bar (do not pass unless all hold):
+- Every completion claim in the artifact is backed by evidence the binding guard could actually point to.
+- All acceptance criteria are met, or the unmet ones are named as accepted residual risk, not hidden.
+- The binding guard came from a different model family than the drafter, and its pass is on the record.
+- No private material leaked and scope stayed inside the stated boundary.
+- A later session could trust the result from the record alone, without re-running the whole review.
+
+Reject bar (send back if any holds):
+- A completion claim asserts more than the evidence shows (the classic 'said it was done but it was not').
+- An acceptance criterion is unmet and is being quietly skipped instead of named as residual risk.
+- Only a same-family reference pass was run; no cross-family binding guard cleared the gate.
+- A finding points to a real, evidence-grounded defect anywhere, even if another guard approved (layered strictness overrides the 'majority liked it' instinct).
+- Private detail leaks, or the work expanded past the stated non-goals.
+
+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/dual-guard/README.md

@@ -0,0 +1,81 @@
+# Dual 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
+
+Cancel shared blind spots with structure instead of a stronger model: a guard from a different model family is the binding gate, and a same-family guard is a non-binding reference, so a fluent answer cannot be trusted just because it reads well.
+
+## When to use
+
+Use before you trust an artifact that another session, another tool, or another person will build on: a release candidate, a public document, a high-risk plan, a completion claim that says work is done, or any output where a wrong 'looks fine' would propagate.
+
+## When not to use
+
+Skip it for low-stakes, easily reversible, or already-verified work: a quick fact lookup, a one-line wording tweak, a throwaway scratch draft, or a step a human is about to fully re-check anyway. Running the full two-layer review on trivial work is pure ceremony cost, 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 guards can point to). The acceptance card or definition of done it claims to meet. The context boundary (goal, scope, non-goals). The verification evidence that supposedly backs the completion claim (command output, test results, a reproduced result). The list of areas the author already knows are unverified. A note of which model family drafted the artifact, so you can pick a guard from a different family for the binding pass.
+
+## Input materials
+
+- Artifact under review, with line numbers or section anchors so a finding can cite an exact spot, not a vibe.
+- Acceptance card / definition of done: the checkable criteria the artifact claims to satisfy.
+- Context boundary: goal, in-scope, and explicit non-goals, so the guards can catch scope drift.
+- Verification evidence: the actual command output, test result, or reproduced behavior the completion claim rests on (or a clear note that none exists).
+- Known-unverified list from the author: what they already flagged as not yet checked.
+- Drafting model family: which family produced the artifact, so the binding guard can be chosen from a different family.
+
+## Process
+
+1. Pick a binding guard from a DIFFERENT model family than the one that drafted the artifact. It does not share the drafter's context window, recent training nudges, or eagerness to please, so it is the pass most likely to see a problem the author cannot. This is the hard gate.
+2. Give the binding guard the artifact plus acceptance card, context boundary, and the evidence list. Ask it to check, in order: does each completion claim have evidence that actually backs it; does the work meet the acceptance criteria; did scope drift past the stated non-goals; is anything private leaking; what is asserted but unproven. Require every finding to point to a specific line, section, or missing piece of evidence.
+3. Optionally run a same-family guard as a REFERENCE pass for a second angle (style, an alternate user path, a missed edge case). Treat its output as input only: it never substitutes for the cross-family pass and never alone clears the gate.
+4. Merge by layered strictness, not by majority vote. This is not a poll. If ANY guard names a real, evidence-grounded blocker, the artifact does not pass, even if the other guard liked it. One concrete defect outweighs two fluent approvals.
+5. Resolve each blocker one of two ways: fix it and re-show the evidence, or carry it explicitly as named residual risk that the human owner accepts on the record. Silent 'good enough' is not allowed.
+6. Record the outcome so a later session can trust it without re-litigating: what was reviewed, which guard was binding vs reference, the findings, the fixes, the residual risk, and the next action.
+
+## Output shape
+
+- Verdict: one of the four standard states — pass / reject / insufficient_evidence / pass_with_risk.
+- Guard level: this is the L3 path (a structured evidence pack reviewed by a different model family), so it can return pass; an L4 pass additionally requires the binding guard to have independently re-run the key evidence and shown that rerun output.
+- Binding guard (cross-family) findings: each tied to a line, section, or missing evidence.
+- Reference guard (same-family) findings: labeled as advisory, not gate-clearing.
+- Merge decision: which findings were decision-changing and why the verdict follows from layered strictness.
+- Required fixes: the concrete change each blocker needs.
+- Residual risk: what stays unverified and who accepted it (a pass_with_risk needs an explicit owner sign-off, not the guard's own say-so).
+- Next action: the exact next step (re-review after fix, hand off, or release).
+
+## Pass bar (what counts as done / safe to trust)
+
+- Every completion claim in the artifact is backed by evidence the binding guard could actually point to.
+- All acceptance criteria are met, or the unmet ones are named as accepted residual risk, not hidden.
+- The binding guard came from a different model family than the drafter, and its pass is on the record.
+- No private material leaked and scope stayed inside the stated boundary.
+- A later session could trust the result from the record alone, without re-running the whole review.
+
+## Reject bar (what sends it back)
+
+- A completion claim asserts more than the evidence shows (the classic 'said it was done but it was not').
+- An acceptance criterion is unmet and is being quietly skipped instead of named as residual risk.
+- Only a same-family reference pass was run; no cross-family binding guard cleared the gate.
+- A finding points to a real, evidence-grounded defect anywhere, even if another guard approved (layered strictness overrides the 'majority liked it' instinct).
+- Private detail leaks, or the work expanded past the stated non-goals.
+
+## Common misuse
+
+- Treating it as a vote: two approvals and one blocker get tallied as 'pass'. It is not a poll; one concrete, evidence-grounded blocker is enough to reject.
+- Using two guards from the SAME model family and calling it dual-guard. Same-family reviewers tend to miss the same things; same-family passes catch fewer real problems than a cross-family pass, so without the cross-family binding guard the structure's whole point is gone.
+- Letting the binding guard 'review' with no acceptance card or evidence, so it grades tone and fluency instead of checking claims against proof.
+- Copying every comment from both guards into the merge instead of keeping only the decision-changing findings, which buries the real blocker in noise.
+- Accepting a warning as a pass without writing down the residual risk or who accepted it, so the next session inherits a hidden gap.
+- Skipping the whole mechanism on a genuinely high-stakes artifact because it 'reads fine' which is exactly the fluent-but-wrong case the cross-family guard exists to catch.
+
+## 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/dual-guard/TEMPLATE.md

@@ -0,0 +1,73 @@
+# Dual Guard Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Cancel shared blind spots with structure instead of a stronger model: a guard from a different model family is the binding gate, and a same-family guard is a non-binding reference, so a fluent answer cannot be trusted just because it reads well.
+
+## Template
+
+### Artifact under review (with line/section refs):
+
+
+### Acceptance source / definition of done:
+
+
+### Drafting model family:
+
+
+### Binding guard (different family) focus:
+
+
+### Binding guard findings (each cites a line/section/missing evidence):
+
+
+### Reference guard (same family) focus and findings (advisory only):
+
+
+### Merge rule = layered strictness (any evidence-grounded blocker = reject; not majority vote):
+
+
+### Guard level reached (L3 cross-family pack, or L4 if the binding guard re-ran the key evidence):
+
+
+### Verdict (pass / reject / insufficient_evidence / pass_with_risk):
+
+
+### Required fixes:
+
+
+### Residual risk and who accepted it (pass_with_risk needs an explicit owner sign-off):
+
+
+### Next action:
+
+
+
+## Pass bar (tick before you trust the result)
+
+- Every completion claim in the artifact is backed by evidence the binding guard could actually point to.
+- All acceptance criteria are met, or the unmet ones are named as accepted residual risk, not hidden.
+- The binding guard came from a different model family than the drafter, and its pass is on the record.
+- No private material leaked and scope stayed inside the stated boundary.
+- A later session could trust the result from the record alone, without re-running the whole review.
+
+## Reject bar (send it back if any of these is true)
+
+- A completion claim asserts more than the evidence shows (the classic 'said it was done but it was not').
+- An acceptance criterion is unmet and is being quietly skipped instead of named as residual risk.
+- Only a same-family reference pass was run; no cross-family binding guard cleared the gate.
+- A finding points to a real, evidence-grounded defect anywhere, even if another guard approved (layered strictness overrides the 'majority liked it' instinct).
+- Private detail leaks, or the work expanded past the stated non-goals.
+
+## 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.