ai-collab-open-system 0.1.0

package/.aict/mechanisms/honest-calibration/README.md

@@ -0,0 +1,81 @@
+# Honest Calibration
+
+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
+
+Offset the model's built-in eagerness to please by pinning one short user-side prefix to the front of every ask for a rating, an evaluation, or a recommendation: be candid, do not inflate, do not over-hedge. The point is not to hope the AI will be honest — it is to know that, left uncalibrated, a model slides back toward the answer that makes you feel good, so you re-aim it on each ask. The prefix pulls the baseline from make-you-happy back to tell-the-truth, and it matters most exactly where the temptation to flatter is highest: when you are asking the AI to judge your own work, your own ability, or your own output.
+
+## When to use
+
+Use whenever you ask the AI to grade, score, place, rank, or recommend — and most of all when the thing being judged is yours: your draft, your plan, your skill level, the quality tier your output would land in, whether something is ready to ship or publish. If a falsely high 'this is great' would cost you (you publish too early, you skip a fix, you misjudge where you really stand), put the calibration prefix in front of the ask.
+
+## When not to use
+
+Do not bolt it onto a plain fact lookup or a direct instruction to carry out — there is no evaluation to calibrate, so the prefix is just noise. 'Be candid, do not inflate' in front of 'what is the capital of X' or 'rename this file' adds nothing, and a calibration ritual stapled to every message trains you to stop noticing it on the one ask where it actually changes the answer. It is also not a license to flip to harsh: the instruction is to stop both inflating AND over-hedging, not to make the AI negative on command.
+
+## Input shape
+
+The specific thing to judge, stated plainly (the draft, the plan, the output, the ability). What the judgment is for (publish / ship / keep iterating / a self-honest gut check), so the AI calibrates to a real bar instead of a vague vibe. The reference frame you want it measured against (a quality tier, a percentile, a named standard, a comparison set) so 'good' has an anchor. The candor prefix itself, placed at the FRONT of the ask, not buried after it. And, when the thing under judgment is your own, an explicit nudge to step outside your point of view and not grade to please you.
+
+## Input materials
+
+- The exact artifact, ability, or output to evaluate — named concretely so the AI grades a real thing, not a generality.
+- The purpose of the judgment (decide whether to publish, whether to ship, whether to keep working, or just to know honestly where you stand), so the bar is the real-world consequence, not a feeling.
+- The reference frame: the quality tier, percentile band, named standard, or comparison set the answer should be measured against, so 'good' or 'B+' is anchored rather than floating.
+- The candor prefix, placed at the FRONT of the request (be candid, do not inflate, do not over-hedge) — position matters, because a prefix sets the stance before the model starts composing the pleasing version.
+- When you are the subject (your work, your skill, your output), an explicit 'step outside my perspective and do not grade to make me feel good' so the highest-flattery case gets the strongest calibration.
+- Optional: permission to deliver the verdict bluntly and lead with the weakest part, so the honest signal is not softened into mush on its way out.
+
+## Process
+
+1. Put the candor prefix first, before the actual ask. Lead the request with 'be candid, do not inflate, do not over-hedge' (or your own words for it) so the stance is set before the model reaches for the agreeable framing. A prefix after the question is half as effective as a prefix before it, because by then the answer is already forming around what would please you.
+2. Anchor the judgment to a real bar, not a vibe. Name the reference frame — a tier, a percentile, a named standard, a comparison set — so the AI cannot retreat to a safely flattering 'it's pretty good'. 'Be candid' with nothing to be candid against just produces a more confident vague compliment.
+3. Apply the strongest calibration when the subject is you. Self-evaluation is the peak-flattery case: the model most wants to please you exactly when you are asking about your own work or ability. Add the explicit 'step outside my point of view and do not grade to make me feel good' here, and treat a suspiciously warm verdict on your own output as a signal to re-ask, not as good news.
+4. Read the answer for the tells of an uncalibrated slide-back: it opens with praise and buries the real critique; every weakness is immediately cushioned ('but this is genuinely strong'); the score drifts upward with no new evidence; it agrees with your own stated hope a little too readily. Any of these means the baseline slid back toward make-you-happy and the prefix needs re-asserting.
+5. Re-aim when it slides. The model does not hold the candid stance forever — over a long thread it relaxes back into the pleasing default. When you catch the tells, restate the prefix and ask for the verdict again; do not accept the warmed-over version just because re-asking feels awkward.
+6. Separate the candid verdict from encouragement, and keep them in that order. A useful honest answer can still end with 'and here is the fastest path up' — but the true placement comes first and unhedged, and the encouragement comes after, clearly marked as the next step rather than as a softener that quietly raises the grade.
+
+## Output shape
+
+- A candid verdict stated first and plainly: the tier, score, percentile, or yes/no, without an opening cushion of praise.
+- The anchor it was measured against (the named tier, percentile, standard, or comparison set), so the verdict is checkable rather than a floating adjective.
+- The weakest part led with, not buried: the single biggest reason it is not higher, stated before any reassurance.
+- No upward drift: the score does not creep higher than the evidence supports, and warmth is not substituted for a number.
+- Encouragement, if any, clearly separated and placed last — the fastest path up, marked as a next step, never folded back into the grade.
+- On a self-evaluation, an explicit note that the AI graded from outside your perspective rather than to please you.
+
+## Pass bar (what counts as done / safe to trust)
+
+- The candor prefix sat at the FRONT of the ask, setting the stance before the answer formed.
+- The verdict is anchored to a named bar (tier / percentile / standard / comparison set), not a floating 'pretty good'.
+- The weakest point is stated first and unhedged, rather than buried under an opening of praise.
+- The score reflects the evidence and did not drift upward, and warmth was not used in place of a real number.
+- On a self-evaluation, the AI grades from outside your perspective and says so, instead of grading to please you.
+- Encouragement, if present, is separated out and placed last as a next step — never blended back into the grade.
+
+## Reject bar (what sends it back)
+
+- The answer opens with praise and the real critique is buried below it (the classic flatter-first slide-back).
+- The verdict is a warm adjective with no anchor — 'this is strong' against nothing checkable.
+- Every weakness is immediately cushioned so no honest signal survives to the reader.
+- The grade crept upward across the thread with no new evidence, tracking your stated hope rather than the work.
+- The prefix was tacked on AFTER the question, so the pleasing version had already formed.
+- The candor was read as a license to be harsh, producing a put-down instead of an inflation-free, hedge-free truth.
+
+## Common misuse
+
+- Stapling the prefix to plain fact lookups and direct instructions, so it becomes background noise you stop noticing on the one ask that needs it.
+- Putting 'be candid' after the question instead of in front of it, so the model has already composed the agreeable answer before the stance lands.
+- Accepting a suspiciously warm verdict on your own work because re-asking feels awkward — the peak-flattery case is exactly where you must re-aim.
+- Treating the prefix as a one-time setting rather than re-asserting it when the thread drifts back toward pleasing you.
+- Flipping the instruction into 'be harsh', so you trade a flattering distortion for a punitive one instead of getting an undistorted read.
+- Letting the encouragement at the end quietly raise the grade ('it's a B, but honestly almost an A') so the candid verdict is undone in its own last line.
+
+## 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/honest-calibration/TEMPLATE.md

@@ -0,0 +1,66 @@
+# Honest Calibration Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Offset the model's built-in eagerness to please by pinning one short user-side prefix to the front of every ask for a rating, an evaluation, or a recommendation: be candid, do not inflate, do not over-hedge. The point is not to hope the AI will be honest — it is to know that, left uncalibrated, a model slides back toward the answer that makes you feel good, so you re-aim it on each ask. The prefix pulls the baseline from make-you-happy back to tell-the-truth, and it matters most exactly where the temptation to flatter is highest: when you are asking the AI to judge your own work, your own ability, or your own output.
+
+## Template
+
+### Candor prefix (paste at the FRONT of the ask): be candid, do not inflate and do not over-hedge; step outside my perspective and do not grade this to make me feel good.
+
+
+### What to judge (the exact draft / plan / output / ability):
+
+
+### What the judgment is for (publish / ship / keep iterating / honest gut check):
+
+
+### Reference frame to measure against (tier / percentile / named standard / comparison set):
+
+
+### Is the subject mine? (if yes, apply the strongest calibration and grade from outside my view):
+
+
+### Candid verdict first (tier / score / percentile / yes-no, no opening praise):
+
+
+### Single biggest reason it is not higher (led with, not cushioned):
+
+
+### Tells of a slide-back to watch for (praise-first / every flaw cushioned / score drifts up / agrees with my hope too fast):
+
+
+### Fastest path up (optional, placed LAST, marked as a next step not a grade-softener):
+
+
+
+## Pass bar (tick before you trust the result)
+
+- The candor prefix sat at the FRONT of the ask, setting the stance before the answer formed.
+- The verdict is anchored to a named bar (tier / percentile / standard / comparison set), not a floating 'pretty good'.
+- The weakest point is stated first and unhedged, rather than buried under an opening of praise.
+- The score reflects the evidence and did not drift upward, and warmth was not used in place of a real number.
+- On a self-evaluation, the AI grades from outside your perspective and says so, instead of grading to please you.
+- Encouragement, if present, is separated out and placed last as a next step — never blended back into the grade.
+
+## Reject bar (send it back if any of these is true)
+
+- The answer opens with praise and the real critique is buried below it (the classic flatter-first slide-back).
+- The verdict is a warm adjective with no anchor — 'this is strong' against nothing checkable.
+- Every weakness is immediately cushioned so no honest signal survives to the reader.
+- The grade crept upward across the thread with no new evidence, tracking your stated hope rather than the work.
+- The prefix was tacked on AFTER the question, so the pleasing version had already formed.
+- The candor was read as a license to be harsh, producing a put-down instead of an inflation-free, hedge-free truth.
+
+## 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/one-click-dispatch/EXAMPLE.synthetic.md

@@ -0,0 +1,15 @@
+# One-Click Dispatch 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 controller sends an implementation packet that says: edit only the synthetic CLI files, run npm test, do not publish, and return changed files plus command output.
+
+## 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/one-click-dispatch/FAILURE_MODES.md

@@ -0,0 +1,16 @@
+# One-Click Dispatch 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
+
+- Dispatch packet contains a full transcript instead of compressed state.
+- Authority is unclear, so the worker edits during a review-only task.
+- The return format omits unverified areas.
+
+## 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/one-click-dispatch/PROMPT.md

@@ -0,0 +1,41 @@
+# One-Click Dispatch Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Turn a messy task into a compact work packet another AI tool can execute without inheriting the whole chat.
+
+## Copy-paste prompt
+
+```text
+Use the One-Click Dispatch mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Turn a messy task into a compact work packet another AI tool can execute without inheriting the whole chat.
+
+Trigger:
+Use when handing a task from a controller session to Codex, Claude Code, Cursor, Cline, Windsurf, or Copilot.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Package only the state required to act.
+2. State authority: read-only, write allowed, review-only, or handoff-only.
+3. Attach acceptance and stop conditions.
+4. Require the worker to return changed artifacts, verification evidence, blockers, and unverified claims.
+
+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/one-click-dispatch/README.md

@@ -0,0 +1,30 @@
+# One-Click Dispatch
+
+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
+
+Turn a messy task into a compact work packet another AI tool can execute without inheriting the whole chat.
+
+## When to use
+
+Use when handing a task from a controller session to Codex, Claude Code, Cursor, Cline, Windsurf, or Copilot.
+
+## Input shape
+
+Goal, files or artifacts, acceptance card, allowed actions, forbidden actions, and expected return shape.
+
+## Process
+
+1. Package only the state required to act.
+2. State authority: read-only, write allowed, review-only, or handoff-only.
+3. Attach acceptance and stop conditions.
+4. Require the worker to return changed artifacts, verification evidence, blockers, and unverified claims.
+
+## 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/one-click-dispatch/TEMPLATE.md

@@ -0,0 +1,38 @@
+# One-Click Dispatch Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Turn a messy task into a compact work packet another AI tool can execute without inheriting the whole chat.
+
+## Template
+
+### Task:
+
+
+### Authority:
+
+
+### Required context:
+
+
+### Acceptance:
+
+
+### Stop conditions:
+
+
+### Return format:
+
+
+### Privacy boundary:
+
+
+
+## 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/plain-language-first-screen/EXAMPLE.synthetic.md

@@ -0,0 +1,15 @@
+# Plain-Language First Screen 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
+
+START_HERE opens with the demo path and raw-chat comparison, then links to architecture docs after the user has something runnable.
+
+## 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/plain-language-first-screen/FAILURE_MODES.md

@@ -0,0 +1,16 @@
+# Plain-Language First Screen 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 first screen becomes a manifesto.
+- The user sees concepts before a runnable path.
+- The guide claims value without a before/after proof.
+
+## 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/plain-language-first-screen/PROMPT.md

@@ -0,0 +1,41 @@
+# Plain-Language First Screen Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Make the first screen explain the result, path, and proof before concepts or framework names.
+
+## Copy-paste prompt
+
+```text
+Use the Plain-Language First Screen mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Make the first screen explain the result, path, and proof before concepts or framework names.
+
+Trigger:
+Use for README, START_HERE, handoff, review results, and any user-facing guide.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Start with what the user can do in ten minutes.
+2. Show before/after instead of abstract philosophy.
+3. Name the files or commands that prove the claim.
+4. Move deeper theory below the first-run path.
+
+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/plain-language-first-screen/README.md

@@ -0,0 +1,30 @@
+# Plain-Language First Screen
+
+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 first screen explain the result, path, and proof before concepts or framework names.
+
+## When to use
+
+Use for README, START_HERE, handoff, review results, and any user-facing guide.
+
+## Input shape
+
+Audience, first action, proof artifact, main contrast, and one next step.
+
+## Process
+
+1. Start with what the user can do in ten minutes.
+2. Show before/after instead of abstract philosophy.
+3. Name the files or commands that prove the claim.
+4. Move deeper theory below the first-run path.
+
+## 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/plain-language-first-screen/TEMPLATE.md

@@ -0,0 +1,38 @@
+# Plain-Language First Screen Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Make the first screen explain the result, path, and proof before concepts or framework names.
+
+## Template
+
+### Audience:
+
+
+### First-screen claim:
+
+
+### Ten-minute action:
+
+
+### Before/after proof:
+
+
+### Files or commands:
+
+
+### What this is not:
+
+
+### Next step:
+
+
+
+## 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/root-cause-brake/EXAMPLE.synthetic.md

@@ -0,0 +1,55 @@
+# Root-Cause Brake 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 data-quarantine feature is blocked twice in a row: round one for an inconsistent status field, round two for the same status field plus a self-check that 'passed' a broken case. Instead of shipping a third patch, the brake trips, the four questions reveal a contract conflict (the status field keeps being redefined) compounded by fake verification (the self-check was cosmetic), and the next version is rebuilt by freezing the contract first — not by adding a third fix.
+
+## Full worked example (filled end to end)
+
+An execution AI is building a 'quarantine' feature for a synthetic records tool: bad records get parked in a holding state instead of deleted. The owner reviews each version with an independent guard. Version 4 is blocked. Version 5 is blocked too. The owner is about to ask for version 6 — and trips the Root-Cause Brake instead.
+
+### Twice-rejected target
+The quarantine feature for the synthetic records tool. Two consecutive blocking reviews: V4 and V5.
+
+### Trip condition met?
+Yes. Same artifact, two blocks in a row. By the rule, version 6 may NOT be another patched draft. Stop and diagnose.
+
+### Findings from block 1 (V4, verbatim)
+BLOCK. The quarantine `status` field is written as the string 'held' in one path and the enum value QUARANTINED in another, so downstream reads disagree about whether a record is parked.
+
+### Findings from block 2 (V5, verbatim)
+BLOCK. The `status` mismatch from V4 is only half-fixed — one more path still writes 'held'. Also: the self-check claims 'all quarantine transitions verified' but it never exercises the restore-from-quarantine path, so a broken restore passed review.
+
+### Patch-on-patch trail
+V4 -> V5 was 'fix the status string in the path the guard named'. It patched the one spot the reviewer pointed at, did not sweep the rest, and added no real test — classic symptom-chasing.
+
+### Q1 Contract conflict?
+YES. Evidence: V4 finding + V5 finding both turn on `status` being two things at once ('held' vs QUARANTINED). The agreed definition of the status field is not frozen, so every patch fixes one writer and leaves others on the old assumption.
+
+### Q2 Fake verification?
+YES. Evidence: V5 finding — the self-check reported 'all transitions verified' while never running the restore path. The check was cosmetic; it passed a case it never tested.
+
+### Q3 Scope too big?
+PARTLY. Evidence: the feature bundles park + restore + audit-log in one unit; the restore path is where the untested gap hid. Not the primary cause, but it widened the surface the fake check let slip.
+
+### Q4 Wrong split?
+NO. Evidence: the task was a single coherent feature; the failures are about contract and verification, not about how the work was divided.
+
+### Named root cause
+A contract conflict on the `status` field (it was never frozen to one representation), made invisible each round by a verification step that only went through the motions. The patches kept fixing the spot the guard named while the unfrozen contract reintroduced the same class of bug elsewhere, and the hollow self-check kept certifying it.
+
+### Owner decision
+Agree with the root cause. Adjustment: freeze the `status` contract to a single enum as step zero of V6, and make the self-check fail first on the restore path before any further work.
+
+### Version 6 direction, rebuilt around the cause (NOT another patch)
+V6 does not start from the V5 patch list. Step 1: define `status` as one enum, single source of truth, and update every writer to it at once. Step 2: write a restore-from-quarantine check that fails against the current code, then make it pass. Only then continue. The brake record (both findings, four answers, cause, decision) is filed so a later session sees why the V4->V5->V6 chain was broken on purpose instead of patched a third time.
+
+## 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/root-cause-brake/FAILURE_MODES.md

@@ -0,0 +1,25 @@
+# Root-Cause Brake 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
+
+- A third patched version goes out because nobody noticed the second block was the trip condition.
+- The four questions get answered without evidence, so the named 'root cause' is just the old symptoms relabeled.
+- The earlier findings are overwritten, so the across-rounds pattern that proves the real cause is lost.
+
+## Common misuse (operator errors that look fine but break the mechanism)
+
+- 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.
+
+## 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/root-cause-brake/PROMPT.md

@@ -0,0 +1,73 @@
+# Root-Cause Brake Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it 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.
+
+## Copy-paste prompt
+
+```text
+Use the Root-Cause Brake mechanism from my local AI Collaboration Open System workspace.
+
+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.
+
+Trigger:
+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.
+
+Do not use when:
+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:
+[paste redacted task material, context package, and acceptance card here]
+
+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.
+
+Return:
+- Decision-changing findings only
+- Evidence used
+- Required fixes
+- Residual risk
+- Next action
+
+Pass bar (do not pass unless all hold):
+- 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 back if any holds):
+- 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.
+
+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.