ai-collab-open-system 0.1.0

package/.aict/mechanisms/feedback-absorption-ledger/EXAMPLE.synthetic.md

@@ -0,0 +1,49 @@
+# Feedback Absorption Ledger 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 merging three reviews of a synthetic spec does not write 'all helpful, will incorporate'. They ledger it: reviewer A's data-shape fix is ABSORBED FULLY (right and clearly scoped); reviewer B's 'add retries everywhere' is ABSORBED WITH A BOUNDARY (yes for the network call, no for the local parse, with the reason); reviewer C's 'rename the module' is REJECTED with an independent reason (the name encodes a deliberate distinction C missed) plus an alternative comment. The resulting mix — one full, one bounded, one rejected — is reported as the outcome of judging each on its merits, explicitly not a quota the controller was aiming for.
+
+## Full worked example (filled end to end)
+
+A maintainer of a synthetic open-source tool gets three reviews on the same pull request and has to merge them into one revision. The instinct is to thank everyone and apply all of it. Instead they run the Feedback Absorption Ledger so the synthesis stays their own judgment.
+
+### Artifact under revision and the bar
+A pull request adding a retry wrapper to a synthetic data-fetch tool. Bar: it must be correct, must not retry non-idempotent work, and must stay readable for the next maintainer.
+
+### Feedback items, listed separately (not merged)
+Item 1 (reviewer A): 'The backoff is fixed-interval; under load this will thundering-herd. Use exponential backoff with jitter.'
+Item 2 (reviewer B): 'Wrap every external call in the retry, not just the fetch — be consistent.'
+Item 3 (reviewer C): 'Rename `fetchOnce` to `fetch`; the `Once` suffix is ugly.'
+Item 4 (reviewer A and reviewer B, same point): 'Add a comment explaining the retry budget.'
+
+### Item 1 — tier + reason
+ABSORB AND REFINE. The direction is right (fixed interval is a real herd risk) and I add the more precise version: exponential backoff WITH a cap, so retries do not grow unbounded on a long outage. What I added beyond A's note: the cap, which A did not mention.
+
+### Item 2 — tier + reason
+ABSORB WITH A BOUNDARY. Yes for idempotent reads, NO for the write path — blindly retrying a non-idempotent write can double-apply it. Boundary stated in code and review reply: retry wraps reads only; writes are explicitly excluded with a reason.
+
+### Item 3 — tier + reason
+REJECT, with an independent reason and an alternative. `Once` is not ugliness — it encodes that the function performs exactly one attempt, which is the contract the retry wrapper depends on; renaming it to `fetch` would blur that distinction and invite someone to add a second internal retry. Alternative offered to C: if the suffix reads oddly, rename to `fetchAttempt`, which keeps the single-attempt meaning. Not rejected to look independent — rejected because the name carries information C's note would erase.
+
+### Item 4 — tier + reason
+ABSORB FULLY. Right and clearly scoped, and the fact that two reviewers raised it does not change the verdict — it would be a full absorb even as a lone note, because a retry budget is genuinely opaque without a comment. (Logged explicitly so the ledger shows substance decided it, not the vote count.)
+
+### Discipline check (both directions)
+Did I reject anything just to look independent? Checked item 3 specifically — no; the reason stands on the contract, and I offered C a real alternative. Did I absorb anything just to avoid friction? Checked item 2 — I could have just said yes to 'wrap everything' to be agreeable, but the write-path boundary is load-bearing, so it gets a boundary, not a full absorb.
+
+### Ratio readout (outcome, not a target)
+Of four items: one full, one refine, one boundary, one reject. I was not aiming for any split — this is simply what judging each point on its merits produced. If all four had been sound I would have absorbed all four; the one rejection is there because one point did not hold, not to keep a ratio looking independent.
+
+### Auditable note
+The PR revision links each change back to its ledger row, so the next maintainer can see why writes are excluded from retry and why `fetchOnce` kept its suffix — the synthesis is traceable to per-item judgment, not a wholesale 'applied all review feedback'.
+
+## 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/feedback-absorption-ledger/FAILURE_MODES.md

@@ -0,0 +1,25 @@
+# Feedback Absorption Ledger 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 reviewer accepts all incoming feedback wholesale and the synthesis becomes a courier for other people's opinions rather than an independent revision.
+- A target ratio creeps in and individual calls get bent to hit it, so the ledger stops recording honest judgment.
+- Rejects and partial-absorbs are left without reasons, so the synthesis cannot be audited and looks the same as reflexive defensiveness.
+
+## Common misuse (operator errors that look fine but break the mechanism)
+
+- Collapsing the items into one 'I took the feedback on board' summary, which is exactly the rubber-stamp the ledger is built to stop.
+- Setting a target ratio ('I should reject about a third to stay independent') and then bending individual calls to hit it — the ratio is an outcome, never a goal.
+- Rejecting a sound point to perform independence, trading the courier failure for an equal-and-opposite defensiveness.
+- Absorbing a weak point to avoid friction with the source, then backfilling a reason that does not really hold.
+- Counting votes — letting three echoes of the same shallow note outweigh one strong objection because three feels like more.
+- Leaving rejects and partials without a stated reason, so the synthesis cannot be audited and looks identical to swatting feedback away.
+
+## 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/feedback-absorption-ledger/PROMPT.md

@@ -0,0 +1,74 @@
+# Feedback Absorption Ledger Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Keep independent judgment alive when you are synthesizing feedback from several sources by scoring each incoming point across five tiers instead of silently rubber-stamping all of it: absorb fully, absorb and refine, absorb with a boundary, partly absorb, or reject with a reason. The trap this defends against is the controller who collects three reviews and quietly accepts everything, becoming a courier for other people's opinions; the equal-and-opposite trap is reflexively rejecting things to look independent. The ledger forces a per-item decision with a stated reason, and treats the absorb/reject ratio as an OUTCOME of honest judgment, never a target to hit.
+
+## Copy-paste prompt
+
+```text
+Use the Feedback Absorption Ledger mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Keep independent judgment alive when you are synthesizing feedback from several sources by scoring each incoming point across five tiers instead of silently rubber-stamping all of it: absorb fully, absorb and refine, absorb with a boundary, partly absorb, or reject with a reason. The trap this defends against is the controller who collects three reviews and quietly accepts everything, becoming a courier for other people's opinions; the equal-and-opposite trap is reflexively rejecting things to look independent. The ledger forces a per-item decision with a stated reason, and treats the absorb/reject ratio as an OUTCOME of honest judgment, never a target to hit.
+
+Trigger:
+Use when you are the one merging feedback from more than one source into a single revision or decision: two or three reviews of the same artifact, a mix of guard verdicts plus a stakeholder's notes, several rounds of comments you have to reconcile, or any moment where 'I got a lot of feedback, now what do I actually do with it' is the real question. It is for the synthesis step, where the temptation to either accept-everything or defend-everything is highest.
+
+Do not use when:
+Skip the full ledger for a single piece of feedback you can simply act on, or a trivial note with no judgment call in it (a typo fix, an obvious correction). Scoring one unambiguous comment across five tiers is ceremony, and a ritual you run on feedback that needed no deliberation trains you to skip it on the genuinely conflicting feedback where the per-item discipline is the whole point.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. List every feedback item separately before deciding anything. Resist forming one overall impression of 'the feedback' — the method only works if each point gets its own row and its own verdict.
+2. Score each item into exactly one of five tiers, and write the reason. (1) ABSORB FULLY: the point is right and its scope is clear — take it as-is. (2) ABSORB AND REFINE: the direction is right but you add a more precise version — keep the intent, improve the execution, and note what you added. (3) ABSORB WITH A BOUNDARY: accept it, but bound where it applies, naming the cases it should and should not cover. (4) PARTLY ABSORB: take one part and set aside or defer the rest, splitting the item into what you took and what you did not. (5) REJECT: decline it, and give an independent reason, contrary evidence, or an alternative — a reject with no reason does not count.
+3. Judge substance, not source weight or vote count. Three sources making the same weak point do not outvote one strong objection; a single sharp dissent can be the item you absorb fully while the majority note gets a boundary. The ledger records what is right, not what is popular.
+4. Hold the two opposite disciplines at once. You may NOT reject a sound point just to look independent or to avoid feeling like a courier; and you may NOT absorb a weak point just to avoid friction or to be agreeable. Both are failures of judgment in opposite directions, and the stated reason on each row is what keeps you honest about which one you might be slipping into.
+5. Treat the ratio as a readout, not a goal. After scoring, you can look at how much you absorbed versus refined, bounded, partly took, or rejected — but that distribution is the RESULT of judging each item honestly. Never nudge an individual call to make the overall ratio look more independent or more agreeable; the moment the ratio drives a row's verdict, the ledger is corrupted.
+6. Record the ledger so the synthesis is auditable. Keep the per-item tier and reason, especially for every reject and partial-absorb, so a later reviewer (or your future self) can see that each point was weighed on its merits rather than waved through or swatted away.
+
+Output shape:
+- One row per feedback item — never a merged 'I considered all the feedback' summary.
+- A single tier per row: absorb fully / absorb and refine / absorb with a boundary / partly absorb / reject.
+- A stated reason on every row, and specifically an independent reason, contrary evidence, or alternative on every reject and partial-absorb.
+- For refine rows, what you added beyond the original; for boundary rows, where it does and does not apply; for partial rows, what was taken and what was set aside.
+- The resulting absorb/reject distribution shown as an outcome readout, with an explicit note that it was not a target.
+- An auditable trail: enough that a later reader can see each point was judged on its merits, not by vote count or by source weight.
+
+Return:
+- Decision-changing findings only
+- Evidence used
+- Required fixes
+- Residual risk
+- Next action
+
+Pass bar (do not pass unless all hold):
+- Every feedback item has its own row and exactly one tier — nothing is merged into a single overall impression.
+- Every reject and every partial-absorb carries an independent reason, contrary evidence, or a named alternative.
+- Items were judged on substance, not on how many sources said them or how senior the source was.
+- Neither failure direction is present: nothing was rejected merely to look independent, nothing absorbed merely to avoid friction.
+- The absorb/reject ratio is presented as an outcome of the per-item calls, with no sign that any row was bent to make the ratio look a certain way.
+- The ledger is auditable: a later reader can see each point was weighed, not waved through or swatted away.
+
+Reject bar (send back if any holds):
+- The feedback was accepted wholesale — 'all good points, I'll incorporate them' — with no per-item decision (the courier failure the ledger exists to prevent).
+- A point was rejected with no reason, contrary evidence, or alternative, so it cannot be told apart from reflexive defensiveness.
+- Decisions tracked vote count or source seniority instead of substance (the majority note won just for being the majority).
+- An individual call was nudged to make the overall ratio look more independent or more agreeable — the ratio drove the verdict.
+- Sound feedback was declined specifically to avoid feeling like a rubber stamp (independence theater), or weak feedback absorbed specifically to keep the peace.
+- The items were blurred into one impression, so there is no auditable trail of which point got what verdict and why.
+
+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/feedback-absorption-ledger/README.md

@@ -0,0 +1,81 @@
+# Feedback Absorption Ledger
+
+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
+
+Keep independent judgment alive when you are synthesizing feedback from several sources by scoring each incoming point across five tiers instead of silently rubber-stamping all of it: absorb fully, absorb and refine, absorb with a boundary, partly absorb, or reject with a reason. The trap this defends against is the controller who collects three reviews and quietly accepts everything, becoming a courier for other people's opinions; the equal-and-opposite trap is reflexively rejecting things to look independent. The ledger forces a per-item decision with a stated reason, and treats the absorb/reject ratio as an OUTCOME of honest judgment, never a target to hit.
+
+## When to use
+
+Use when you are the one merging feedback from more than one source into a single revision or decision: two or three reviews of the same artifact, a mix of guard verdicts plus a stakeholder's notes, several rounds of comments you have to reconcile, or any moment where 'I got a lot of feedback, now what do I actually do with it' is the real question. It is for the synthesis step, where the temptation to either accept-everything or defend-everything is highest.
+
+## When not to use
+
+Skip the full ledger for a single piece of feedback you can simply act on, or a trivial note with no judgment call in it (a typo fix, an obvious correction). Scoring one unambiguous comment across five tiers is ceremony, and a ritual you run on feedback that needed no deliberation trains you to skip it on the genuinely conflicting feedback where the per-item discipline is the whole point.
+
+## Input shape
+
+Every incoming feedback item, kept as separate line items rather than blurred into one impression (so each can get its own decision). For each, enough of the original to judge it on its merits — what was said, by whom, and the reason behind it if given. The artifact or decision the feedback is about, and the bar it is being held to, so 'absorb' or 'reject' is measured against something. Your own read on each, because the ledger records YOUR judgment, not a vote tally. And a clear understanding that the final ratio is whatever honest per-item judgment produces — you are not aiming for a number.
+
+## Input materials
+
+- The full set of feedback items, listed separately — one row per point, not a single merged blob, because the method's whole value is a per-item decision.
+- For each item: what was actually said, the source, and the stated reason if there is one, so you judge the substance instead of the loudest voice.
+- The artifact or decision under revision and the bar it must meet, so each absorb/refine/reject call is measured against a real standard.
+- Your own independent read on each item — this is a judgment ledger, not a poll; agreement among sources does not auto-win and a lone dissent is not auto-dismissed.
+- An explicit reason attached to every reject and every partial-absorb, because an unexplained rejection is indistinguishable from defensiveness.
+- A clear stance going in that the absorb/reject ratio is an outcome of honest judgment, not a quota — you are forbidden both from rejecting to look independent and from accepting to avoid friction.
+
+## Process
+
+1. List every feedback item separately before deciding anything. Resist forming one overall impression of 'the feedback' — the method only works if each point gets its own row and its own verdict.
+2. Score each item into exactly one of five tiers, and write the reason. (1) ABSORB FULLY: the point is right and its scope is clear — take it as-is. (2) ABSORB AND REFINE: the direction is right but you add a more precise version — keep the intent, improve the execution, and note what you added. (3) ABSORB WITH A BOUNDARY: accept it, but bound where it applies, naming the cases it should and should not cover. (4) PARTLY ABSORB: take one part and set aside or defer the rest, splitting the item into what you took and what you did not. (5) REJECT: decline it, and give an independent reason, contrary evidence, or an alternative — a reject with no reason does not count.
+3. Judge substance, not source weight or vote count. Three sources making the same weak point do not outvote one strong objection; a single sharp dissent can be the item you absorb fully while the majority note gets a boundary. The ledger records what is right, not what is popular.
+4. Hold the two opposite disciplines at once. You may NOT reject a sound point just to look independent or to avoid feeling like a courier; and you may NOT absorb a weak point just to avoid friction or to be agreeable. Both are failures of judgment in opposite directions, and the stated reason on each row is what keeps you honest about which one you might be slipping into.
+5. Treat the ratio as a readout, not a goal. After scoring, you can look at how much you absorbed versus refined, bounded, partly took, or rejected — but that distribution is the RESULT of judging each item honestly. Never nudge an individual call to make the overall ratio look more independent or more agreeable; the moment the ratio drives a row's verdict, the ledger is corrupted.
+6. Record the ledger so the synthesis is auditable. Keep the per-item tier and reason, especially for every reject and partial-absorb, so a later reviewer (or your future self) can see that each point was weighed on its merits rather than waved through or swatted away.
+
+## Output shape
+
+- One row per feedback item — never a merged 'I considered all the feedback' summary.
+- A single tier per row: absorb fully / absorb and refine / absorb with a boundary / partly absorb / reject.
+- A stated reason on every row, and specifically an independent reason, contrary evidence, or alternative on every reject and partial-absorb.
+- For refine rows, what you added beyond the original; for boundary rows, where it does and does not apply; for partial rows, what was taken and what was set aside.
+- The resulting absorb/reject distribution shown as an outcome readout, with an explicit note that it was not a target.
+- An auditable trail: enough that a later reader can see each point was judged on its merits, not by vote count or by source weight.
+
+## Pass bar (what counts as done / safe to trust)
+
+- Every feedback item has its own row and exactly one tier — nothing is merged into a single overall impression.
+- Every reject and every partial-absorb carries an independent reason, contrary evidence, or a named alternative.
+- Items were judged on substance, not on how many sources said them or how senior the source was.
+- Neither failure direction is present: nothing was rejected merely to look independent, nothing absorbed merely to avoid friction.
+- The absorb/reject ratio is presented as an outcome of the per-item calls, with no sign that any row was bent to make the ratio look a certain way.
+- The ledger is auditable: a later reader can see each point was weighed, not waved through or swatted away.
+
+## Reject bar (what sends it back)
+
+- The feedback was accepted wholesale — 'all good points, I'll incorporate them' — with no per-item decision (the courier failure the ledger exists to prevent).
+- A point was rejected with no reason, contrary evidence, or alternative, so it cannot be told apart from reflexive defensiveness.
+- Decisions tracked vote count or source seniority instead of substance (the majority note won just for being the majority).
+- An individual call was nudged to make the overall ratio look more independent or more agreeable — the ratio drove the verdict.
+- Sound feedback was declined specifically to avoid feeling like a rubber stamp (independence theater), or weak feedback absorbed specifically to keep the peace.
+- The items were blurred into one impression, so there is no auditable trail of which point got what verdict and why.
+
+## Common misuse
+
+- Collapsing the items into one 'I took the feedback on board' summary, which is exactly the rubber-stamp the ledger is built to stop.
+- Setting a target ratio ('I should reject about a third to stay independent') and then bending individual calls to hit it — the ratio is an outcome, never a goal.
+- Rejecting a sound point to perform independence, trading the courier failure for an equal-and-opposite defensiveness.
+- Absorbing a weak point to avoid friction with the source, then backfilling a reason that does not really hold.
+- Counting votes — letting three echoes of the same shallow note outweigh one strong objection because three feels like more.
+- Leaving rejects and partials without a stated reason, so the synthesis cannot be audited and looks identical to swatting feedback away.
+
+## 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/feedback-absorption-ledger/TEMPLATE.md

@@ -0,0 +1,69 @@
+# Feedback Absorption Ledger Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Keep independent judgment alive when you are synthesizing feedback from several sources by scoring each incoming point across five tiers instead of silently rubber-stamping all of it: absorb fully, absorb and refine, absorb with a boundary, partly absorb, or reject with a reason. The trap this defends against is the controller who collects three reviews and quietly accepts everything, becoming a courier for other people's opinions; the equal-and-opposite trap is reflexively rejecting things to look independent. The ledger forces a per-item decision with a stated reason, and treats the absorb/reject ratio as an OUTCOME of honest judgment, never a target to hit.
+
+## Template
+
+### Artifact / decision under revision, and the bar it must meet:
+
+
+### Feedback items, listed separately (one row each — do not merge):
+
+
+### Item 1 — what was said / source / its reason:
+
+
+### Item 1 — tier (absorb fully / refine / boundary / partly / reject) + your reason:
+
+
+### Item 2 — what was said / source / its reason:
+
+
+### Item 2 — tier + your reason:
+
+
+### (repeat one row per item — every reject and partial needs an independent reason, contrary evidence, or an alternative)
+
+
+### Discipline check: did I reject anything just to look independent, or absorb anything just to avoid friction?
+
+
+### Ratio readout (how much absorbed / refined / bounded / partly / rejected) — stated as an OUTCOME, not a target:
+
+
+### Auditable note: the synthesis a later reviewer can trace back to per-item judgment:
+
+
+
+## Pass bar (tick before you trust the result)
+
+- Every feedback item has its own row and exactly one tier — nothing is merged into a single overall impression.
+- Every reject and every partial-absorb carries an independent reason, contrary evidence, or a named alternative.
+- Items were judged on substance, not on how many sources said them or how senior the source was.
+- Neither failure direction is present: nothing was rejected merely to look independent, nothing absorbed merely to avoid friction.
+- The absorb/reject ratio is presented as an outcome of the per-item calls, with no sign that any row was bent to make the ratio look a certain way.
+- The ledger is auditable: a later reader can see each point was weighed, not waved through or swatted away.
+
+## Reject bar (send it back if any of these is true)
+
+- The feedback was accepted wholesale — 'all good points, I'll incorporate them' — with no per-item decision (the courier failure the ledger exists to prevent).
+- A point was rejected with no reason, contrary evidence, or alternative, so it cannot be told apart from reflexive defensiveness.
+- Decisions tracked vote count or source seniority instead of substance (the majority note won just for being the majority).
+- An individual call was nudged to make the overall ratio look more independent or more agreeable — the ratio drove the verdict.
+- Sound feedback was declined specifically to avoid feeling like a rubber stamp (independence theater), or weak feedback absorbed specifically to keep the peace.
+- The items were blurred into one impression, so there is no auditable trail of which point got what verdict and why.
+
+## 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/half-product-review/EXAMPLE.synthetic.md

@@ -0,0 +1,15 @@
+# Half-Product Review 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 README says complete OS, but the generated workspace lacks mechanism packages. Review label is candidate, not publishable, until init creates those files.
+
+## 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/half-product-review/FAILURE_MODES.md

@@ -0,0 +1,16 @@
+# Half-Product Review 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
+
+- Review accepts impressive documentation without running init.
+- The release label hides what is still only a candidate.
+- The reviewer checks only root docs and misses generated workspace drift.
+
+## 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/half-product-review/PROMPT.md

@@ -0,0 +1,41 @@
+# Half-Product Review Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Block confident claims when the project has docs, demos, or architecture but no runnable first experience.
+
+## Copy-paste prompt
+
+```text
+Use the Half-Product Review mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Block confident claims when the project has docs, demos, or architecture but no runnable first experience.
+
+Trigger:
+Use before release, README polish, launch copy, or any claim that a stranger can use the system.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Inspect the first ten minutes as a user would experience them.
+2. Check whether docs point to runnable artifacts.
+3. Reject strategy prose that is not backed by files or commands.
+4. List the smallest fixes required before public labeling.
+
+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/half-product-review/README.md

@@ -0,0 +1,30 @@
+# Half-Product Review
+
+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
+
+Block confident claims when the project has docs, demos, or architecture but no runnable first experience.
+
+## When to use
+
+Use before release, README polish, launch copy, or any claim that a stranger can use the system.
+
+## Input shape
+
+README, START_HERE, CLI output, generated workspace, demo path, tests, and known gaps.
+
+## Process
+
+1. Inspect the first ten minutes as a user would experience them.
+2. Check whether docs point to runnable artifacts.
+3. Reject strategy prose that is not backed by files or commands.
+4. List the smallest fixes required before public labeling.
+
+## 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/half-product-review/TEMPLATE.md

@@ -0,0 +1,38 @@
+# Half-Product Review Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Block confident claims when the project has docs, demos, or architecture but no runnable first experience.
+
+## Template
+
+### Claim under review:
+
+
+### First-run path:
+
+
+### Runnable artifacts:
+
+
+### Missing user proof:
+
+
+### Overclaim risk:
+
+
+### Required fixes:
+
+
+### Release label:
+
+
+
+## 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/handoff-abc/EXAMPLE.synthetic.md

@@ -0,0 +1,47 @@
+# Handoff A/B/C 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
+
+An A/B/C handoff: mode B (programmatic), current state says the feature is implemented and unit-tested, evidence is the passing test output, the blocker is an un-run package dry-run, the next concrete action is 'run the package dry-run against a temp cache before release labeling', and the baseline is the named commit — so a fresh executor continues without re-reading the chat.
+
+## Full worked example (filled end to end)
+
+Session 1 (a controller AI in one tool) gets a synthetic note app close to release but runs low on context before the final packaging check. Rather than dump the chat on whoever continues, it writes a Handoff A/B/C packet. Session 2 — a different AI tool entirely, with none of session 1's memory — reads the packet and picks up cleanly.
+
+### Handoff mode + why
+Mode B (programmatic). A defined, bounded task remains (one packaging check, then a release-label decision) and it will be handed to a separate executor that must run it on its own, so the packet is fully self-contained — not an A-style in-place resume.
+
+### Current state (as fact)
+- Done: the feature is implemented; the unit suite passes; a cross-family guard review accepted the completion claim after an earlier keyboard gap was fixed.
+- In flight: nothing actively running.
+- Not started: the package dry-run (pack the project in a temp directory and confirm every required file ships) and the final release-label decision that depends on it.
+
+### Evidence behind each 'done'
+- 'Unit suite passes' — evidence: the test command's output, all green, captured in the run log.
+- 'Guard review accepted' — evidence: the recorded verdict from the binding cross-family pass, which named the earlier gap and then cleared it after the fix.
+- 'Package dry-run' — NO evidence yet; it has not been run. Flagged so the receiver does not assume it.
+
+### Blocker / waiting-on
+Not blocked, but waiting on one thing before release labeling: the package dry-run has to run clean. The release label must stay 'candidate' until that output exists.
+
+### Next concrete action
+Run the package dry-run against a temp cache and confirm the file list contains every required file. If the list is complete, move the release label from 'candidate' to 'releasable'. If anything is missing, file it as the next fix and keep the label at 'candidate'.
+
+### Baseline
+Start from the named release-candidate commit on the release branch (the one whose log entry records the accepted guard review). Do not start from any local working copy that has uncommitted edits — pull the exact commit first, so the dry-run reflects what would actually ship.
+
+### Stop condition
+This handoff ends once the dry-run has run and the release label has been set accordingly. At that point the receiver owns the result; if the label moves to 'releasable', the next step is a separate release handoff, not a continuation of this one.
+
+### What session 2 actually does first
+Session 2 — a different tool with zero shared memory — reads the packet, checks out the named baseline commit (not its own stale copy), and runs exactly the one next action: the package dry-run against a temp cache. It never has to ask 'what was the background?' or 'where were we?' — the packet already answered both. The dry-run lists every required file, so session 2 flips the label to 'releasable' and writes a short follow-on note. The whole continuation cost the human zero re-explanation.
+
+## 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/handoff-abc/FAILURE_MODES.md

@@ -0,0 +1,25 @@
+# Handoff A/B/C 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 current-state block includes guesses dressed up as confirmed facts.
+- The next-action section lists options but never marks the single first move.
+- The baseline is omitted, so the receiver continues from the wrong version.
+
+## Common misuse (operator errors that look fine but break the mechanism)
+
+- Writing every handoff as a maximal B packet, including a two-line same-tool resume, so the heavy ceremony makes people stop writing handoffs at all.
+- Letting the current-state block drift into wishful 'basically done' instead of fact, so the receiver trusts work that was never verified.
+- Giving the state with no evidence and no 'unverified' label, so a guess gets inherited as a confirmed fact.
+- Listing decision points and options but no single concrete next action, leaving the receiver to re-derive 'so what do I actually do first?'.
+- Skipping the baseline because 'it's obvious', then a parallel edit or stale checkout makes the receiver continue on the wrong copy.
+- Writing a packet that silently assumes the original chat history, so it only works for the same session it was meant to replace.
+
+## 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/handoff-abc/PROMPT.md

@@ -0,0 +1,75 @@
+# Handoff A/B/C Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Externalize the current state into a structured handoff packet so ANY AI or session can pick up from where the work actually is, instead of the human re-explaining the background every time a tool or session changes. A/B/C are three handoff modes for three situations: A = high-interaction handoff (a human and AI trading turns inside the same tool, lightweight resume); B = programmatic handoff (a clear task an executor picks up and drives to completion on its own); C = delivery overview (a human-facing total account of what one phase produced). Whichever mode, the packet carries the same load-bearing fields so the receiver never starts from zero.
+
+## Copy-paste prompt
+
+```text
+Use the Handoff A/B/C mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Externalize the current state into a structured handoff packet so ANY AI or session can pick up from where the work actually is, instead of the human re-explaining the background every time a tool or session changes. A/B/C are three handoff modes for three situations: A = high-interaction handoff (a human and AI trading turns inside the same tool, lightweight resume); B = programmatic handoff (a clear task an executor picks up and drives to completion on its own); C = delivery overview (a human-facing total account of what one phase produced). Whichever mode, the packet carries the same load-bearing fields so the receiver never starts from zero.
+
+Trigger:
+Use whenever continuity is about to break or pass to someone else: a session stops with the work half-done, a different AI tool takes over, a long task crosses a natural seam, or a phase finishes and someone needs the result without reading the whole chat. Pick A for a same-tool resume, B for handing a defined task to an executor, C for reporting a finished phase to a human.
+
+Do not use when:
+Skip a full handoff packet for work that is not actually being passed on: a single self-contained reply you finish in the same turn, a throwaway exploration nobody will continue, or a trivial step where re-explaining the context would take less than writing the packet. A heavy handoff on work that never gets handed off is pure overhead, and overhead with no payoff trains people to skip the packet when a real handoff finally needs it.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Pick the handoff mode first. A = high-interaction: a human and AI are mid-conversation in one tool and you just need a lightweight 'where we are' so the next turn continues cleanly. B = programmatic: you are handing a defined task to an executor (another tool or fresh session) that will run it to completion on its own, so the packet must be self-contained. C = delivery overview: a phase is finished and a human needs the total account, so the packet is a readable result summary, not a work ticket. The mode decides how much the packet carries.
+2. Write the current state as fact, not optimism. Say what is actually done, what is in flight, and what has not started. Resist 'basically done' — if it is not verified, it is not done. This block is the whole point: it is what lets the receiver skip 're-explain the background'.
+3. Attach the evidence for each claimed-done item: the test that passed, the command output, the reviewed artifact. Where there is no evidence yet, say so plainly. State without evidence is a guess wearing a fact's clothes.
+4. Name the blocker or waiting-on, if any, and the single most concrete next action. The next action must be specific enough to act on immediately — 'run the package dry-run against a temp cache and check the file list', not 'continue the task'.
+5. Pin the baseline: the exact commit / version / branch / state the receiver starts from. Without it, a parallel edit or a stale copy silently diverges and the handoff lands on the wrong work.
+6. Hand off in the chosen mode and stop at the stated stop condition. For A, keep it short and resume in place. For B, the executor takes it and drives to completion. For C, the human reads the overview and decides. Do not pad an A resume into a full B packet, and do not shrink a B packet a stranger must run alone down to an A-sized note.
+
+Output shape:
+- Handoff mode: A (high-interaction resume) / B (programmatic task) / C (delivery overview), and one line on why that mode fits.
+- Current state: what is done / in flight / not started, written as fact.
+- Evidence: the proof behind each 'done', or an explicit 'no evidence yet'.
+- Blocker / waiting-on: what is stopping progress, or 'none'.
+- Next concrete action: the single specific first move the receiver should make.
+- Baseline: the exact commit / version / branch / state to start from.
+- Stop condition: where this handoff ends and the receiver takes over.
+
+Return:
+- Decision-changing findings only
+- Evidence used
+- Required fixes
+- Residual risk
+- Next action
+
+Pass bar (do not pass unless all hold):
+- The handoff mode (A / B / C) is named and fits the situation — a same-tool resume is not bloated into a full task packet, and a stranger-runnable task is not shrunk to a one-liner.
+- The current state is written as fact, with no 'basically done' standing in for unverified work.
+- Every claimed-done item has evidence attached, or is explicitly marked 'no evidence yet'.
+- There is exactly one concrete next action the receiver can act on without asking what to do first.
+- The baseline is pinned (commit / version / branch / state), so the receiver cannot pick up the wrong copy.
+- A receiver with no access to the original chat could continue from this packet alone.
+
+Reject bar (send back if any holds):
+- No mode is chosen, so the packet is either too thin for a stranger to run or too heavy for a quick same-tool resume.
+- The current state hides unverified work behind 'basically done' or 'almost there'.
+- A 'done' claim has no evidence and is not marked as unverified — the receiver inherits a hidden gap.
+- There is no concrete next action, or there are five vague ones and no single first move.
+- The baseline is missing, so the receiver can silently start from the wrong version or a stale copy.
+- The packet only makes sense to someone who already read the whole conversation, which defeats the purpose.
+
+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.