ai-collab-open-system 0.1.0

package/.aict/mechanisms/handoff-abc/README.md

@@ -0,0 +1,82 @@
+# Handoff A/B/C
+
+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
+
+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.
+
+## When to use
+
+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.
+
+## When not to use
+
+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 shape
+
+Where the work is now (what is done, in plain state terms). The evidence that backs that state (command output, test result, a reviewed artifact, or a clear note that none exists yet). What it is blocked or waiting on, if anything. The single most concrete next action the receiver should take first. The baseline: the exact version, commit, branch, or state the receiver should start from, so they do not pick up the wrong copy. Which handoff mode applies (A high-interaction / B programmatic / C delivery overview), because it changes how much context the packet carries.
+
+## Input materials
+
+- Current state — where the work actually is, written as fact not hope: what is finished, what is in flight, what has not been started. This is the field that replaces 're-explain the background'.
+- Supporting evidence — the proof each piece of 'done' rests on (a passing test, a command's output, a reviewed file), or an explicit 'no evidence yet' so the receiver does not over-trust the state.
+- Blocker / waiting-on — what is stopping forward progress right now (a missing decision, an unfinished dependency, an unanswered question), or 'none'.
+- Next concrete action — the one specific first move the receiver should make, phrased so they can act without asking 'so what do I do first?'.
+- Baseline — the exact starting point: version, commit, branch, file set, or named state the receiver must begin from, so a handoff cannot land on the wrong copy.
+- Handoff mode — A (high-interaction same-tool resume), B (programmatic task an executor drives alone), or C (delivery overview for a human), since the mode sets how lightweight or complete the packet should be.
+
+## 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.
+
+## Pass bar (what counts as done / safe to trust)
+
+- 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 (what sends it back)
+
+- 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.
+
+## Common misuse
+
+- 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.
+
+## 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/handoff-abc/TEMPLATE.md

@@ -0,0 +1,60 @@
+# Handoff A/B/C Template
+
+AI Collaboration Open System mechanism card. Fill this 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.
+
+## Template
+
+### Handoff mode (A high-interaction / B programmatic / C delivery overview) + why this mode:
+
+
+### Current state (done / in flight / not started — as fact, not 'basically done'):
+
+
+### Evidence behind each 'done' (or explicit 'no evidence yet'):
+
+
+### Blocker / waiting-on (or 'none'):
+
+
+### Next concrete action (one specific first move the receiver can act on):
+
+
+### Baseline (exact commit / version / branch / state to start from):
+
+
+### Stop condition (where this handoff ends and the receiver takes over):
+
+
+
+## Pass bar (tick before you trust the result)
+
+- 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 it back if any of these is true)
+
+- 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.
+
+## 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/harvest-and-erc/EXAMPLE.synthetic.md

@@ -0,0 +1,43 @@
+# Harvest and External Recap 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 single-conversation harvest turns one discussion into two cards — a decision card ('chose the temp-cache dry-run path because it isolates the local-cache failure') and a lesson card ('do not label a release before the packaged smoke test runs') — each redacted into public-safe wording, confirmed by the human, and filed; ERC would do the same across several past sessions, but only under its fresh-session-plus-explicit-role double lock.
+
+## Full worked example (filled end to end)
+
+A working session ends with a real choice having been made about how to verify a synthetic app's release. The discussion is full of useful judgment that would otherwise evaporate. The human says 'harvest this', so the AI sweeps the conversation, proposes cards, redacts them, and files the confirmed ones. (An External Recap would look the same but span several past sessions — here it is a single-conversation harvest, so the ERC double lock is noted as not engaged.)
+
+### Source conversation swept
+One working session that debated how to confirm a release was safe, hit a snag with a local cache during packaging, and settled on a specific verification path.
+
+### Candidate items by type
+- Decision: the team chose to run the package dry-run against a temporary cache rather than the default local cache.
+- Lesson: an earlier near-miss happened because a release was labeled before the packaged smoke test had run.
+- (Considered and dropped) a passing remark about file naming — one-off, no reuse value, not carded.
+
+### Harvest cards
+Card 1 — DECISION. What: when packaging fails only because of a stale local cache, run the dry-run against a temporary cache to isolate the real file-list check from the cache noise. Why reusable: the same cache trap recurs across releases. Target knowledge base: the team's release-practices notes.
+Card 2 — LESSON. What: never move a release label from 'candidate' to 'releasable' before the packaged smoke test has actually run and shown a complete file list. Why reusable: it is a guardrail that prevents shipping an incomplete package. Target knowledge base: the release-practices notes, under pre-release checks.
+
+### Redaction record (before filing)
+Replaced the specific app name with 'a synthetic note app'; replaced concrete local cache paths with 'the local cache' / 'a temporary cache'; removed the contributor's name and referred to 'the human' / 'the team'. No real names, paths, or internal numbers remain on either card.
+
+### Repeat evidence for the rule
+Card 2 is proposed as a standing rule, so it is backed by more than this one chat: the same 'labeled too early' miss had shown up in a prior release loop. Two occurrences, not one, justify generalizing it into a rule. Card 1 is filed as a reusable method, not a hard rule, so it needs less.
+
+### Human confirmation per card
+Card 1: confirmed, filed as written. Card 2: confirmed with a small edit (the human tightened 'smoke test' to 'packaged smoke test' for precision), then filed. The dropped file-naming remark: confirmed dropped.
+
+### ERC double-lock check
+Not engaged. This is a single-conversation harvest inside the working session, not a cross-session recap. The External Recap role would require a brand-new session AND an explicit human declaration of that role before it could run across several past conversations; neither applies here, so harvest runs in its ordinary single-conversation form.
+
+## 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/harvest-and-erc/FAILURE_MODES.md

@@ -0,0 +1,25 @@
+# Harvest and External Recap 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
+
+- Harvest stores every detail and becomes clutter.
+- External recap exposes private source material.
+- A single incident becomes a permanent rule without repeated evidence.
+
+## Common misuse (operator errors that look fine but break the mechanism)
+
+- Treating harvest as 'save the whole transcript' — storing everything as cards until the knowledge base is clutter no one reads.
+- Filing a genuinely useful card before redacting it, so a real name, local path, or internal number leaks into the knowledge base.
+- Generalizing from one bad run into a permanent rule, so a single incident hardens into law without the pattern ever repeating.
+- Writing cards straight into the knowledge base without the human's confirmation, turning 'propose' into 'decide'.
+- Slipping into the External Recap role mid-conversation or in a live working session, so ERC fires without its double lock and sweeps ordinary chat.
+- Letting ERC paste or rewrite the raw source conversations instead of producing redacted, confirmable recap cards — which re-exposes exactly the private material harvest is supposed to strip.
+
+## 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/harvest-and-erc/PROMPT.md

@@ -0,0 +1,74 @@
+# Harvest and External Recap 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 reusable value from leaking away. Valuable decisions, lessons, methods, and stable preferences get buried in long conversations and are never recovered. Harvest sweeps a conversation, lifts the reusable bits into harvest cards (one card per item — a decision, a lesson, a method, a stable preference), the human confirms them, and they land in the right knowledge base. Redaction is a built-in step, not an afterthought: before anything is filed, private material is rewritten into a general, public-safe form. External Recap (ERC) is a separate, dedicated role that runs harvest across MANY conversations at once — guarded by a double lock (a brand-new session AND the human explicitly declaring that role) so an ordinary chat is never swept by accident.
+
+## Copy-paste prompt
+
+```text
+Use the Harvest and External Recap mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Stop reusable value from leaking away. Valuable decisions, lessons, methods, and stable preferences get buried in long conversations and are never recovered. Harvest sweeps a conversation, lifts the reusable bits into harvest cards (one card per item — a decision, a lesson, a method, a stable preference), the human confirms them, and they land in the right knowledge base. Redaction is a built-in step, not an afterthought: before anything is filed, private material is rewritten into a general, public-safe form. External Recap (ERC) is a separate, dedicated role that runs harvest across MANY conversations at once — guarded by a double lock (a brand-new session AND the human explicitly declaring that role) so an ordinary chat is never swept by accident.
+
+Trigger:
+Run a single-conversation harvest when a discussion produced something worth keeping: a real decision got made, a lesson was paid for, a method was figured out, a stable preference surfaced, or a loop finished. Enter the External Recap role only under the double lock — a fresh session plus an explicit human declaration of the recap role — and only when the job is genuinely cross-conversation (recapping several past sessions at once, not extracting from the current one).
+
+Do not use when:
+Do not harvest a chat that produced nothing durable: a quick fact lookup, a dead-end exploration, a routine step with no reusable insight. Do not let a one-off incident become a permanent rule before the pattern has actually repeated. And do not slip into the External Recap role mid-conversation or in an active working session — without the double lock, ERC would fire on everyday chat and bury the knowledge base in low-value cards. Harvesting noise is worse than missing it: a knowledge base full of trivia is one nobody trusts or reads.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Sweep the source conversation end to end and pull out candidate reusable items, each tagged by type: decision, lesson, method, or stable preference. Do not generalize from a single occurrence — a one-off only becomes a rule once the pattern has actually repeated.
+2. Turn each candidate into a harvest card: one item per card, stating what it is, why it is reusable, and where it should be filed. A decision card records the choice and the reason; a lesson card records what went wrong and what to do differently; a method card records the repeatable steps; a preference card records the stable want and the evidence it is stable.
+3. Redact as a built-in step, before filing — never after. Replace private material (real names, local paths, internal numbers, customer or person references) with general, public-safe wording. A card that still carries private specifics is not ready to file, no matter how useful it is.
+4. Show the cards to the human and let them confirm, edit, or drop each one. Harvest proposes; the human disposes. Nothing lands in a knowledge base on the AI's say-so alone.
+5. File each confirmed, redacted card into its target knowledge base, and log it so the same insight is not re-harvested next time.
+6. For External Recap (ERC): only with the double lock satisfied (fresh session + explicit human role declaration), run the same harvest across the named set of prior conversations, produce cross-conversation cards and candidates, and hand them back for the human to confirm — recapping, not rewriting the source history, and still redacting before anything is filed.
+
+Output shape:
+- Harvest cards: one per reusable item, each tagged decision / lesson / method / stable preference, with what it is and why it is reusable.
+- Target knowledge base for each card: where it lands once confirmed.
+- Redaction record: which private specifics were rewritten into general form before filing.
+- Repeat evidence for any card proposed as a rule: the occurrences that justify generalizing.
+- Human confirmation: the yes / edit / drop decision recorded per card.
+- ERC scope (ERC only): the set of conversations recapped and the double-lock confirmation that authorized the role.
+
+Return:
+- Decision-changing findings only
+- Evidence used
+- Required fixes
+- Residual risk
+- Next action
+
+Pass bar (do not pass unless all hold):
+- Each reusable item became its own card, tagged by type, instead of a vague 'lessons learned' blob.
+- Every card was redacted into public-safe wording before filing — no private names, paths, internal numbers, or person references survive.
+- Anything proposed as a reusable rule rests on a repeated pattern, not a single incident.
+- The human confirmed (or edited / dropped) each card; nothing was filed on the AI's say-so alone.
+- Each confirmed card landed in a named knowledge base and was logged so it is not re-harvested.
+- If the External Recap role was used, the double lock (fresh session + explicit role declaration) was satisfied and recorded.
+
+Reject bar (send back if any holds):
+- Harvest stored every detail as cards, so the knowledge base fills with trivia and nobody trusts it.
+- A card was filed with private specifics still in it — redaction was skipped or left for 'later'.
+- A single occurrence was promoted straight to a permanent rule with no repeated evidence.
+- Cards were written into a knowledge base without the human confirming them.
+- The External Recap role ran without the double lock — on an everyday chat or inside an active working session.
+- ERC rewrote or exposed the raw source history instead of producing redacted, confirmable recap cards.
+
+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/harvest-and-erc/README.md

@@ -0,0 +1,81 @@
+# Harvest and External Recap
+
+Part of the AI Collaboration Open System. This is a local-first, public-safe mechanism package you can copy into Claude Code, Codex, Cursor, Cline, Windsurf, or Copilot.
+
+## Purpose
+
+Stop reusable value from leaking away. Valuable decisions, lessons, methods, and stable preferences get buried in long conversations and are never recovered. Harvest sweeps a conversation, lifts the reusable bits into harvest cards (one card per item — a decision, a lesson, a method, a stable preference), the human confirms them, and they land in the right knowledge base. Redaction is a built-in step, not an afterthought: before anything is filed, private material is rewritten into a general, public-safe form. External Recap (ERC) is a separate, dedicated role that runs harvest across MANY conversations at once — guarded by a double lock (a brand-new session AND the human explicitly declaring that role) so an ordinary chat is never swept by accident.
+
+## When to use
+
+Run a single-conversation harvest when a discussion produced something worth keeping: a real decision got made, a lesson was paid for, a method was figured out, a stable preference surfaced, or a loop finished. Enter the External Recap role only under the double lock — a fresh session plus an explicit human declaration of the recap role — and only when the job is genuinely cross-conversation (recapping several past sessions at once, not extracting from the current one).
+
+## When not to use
+
+Do not harvest a chat that produced nothing durable: a quick fact lookup, a dead-end exploration, a routine step with no reusable insight. Do not let a one-off incident become a permanent rule before the pattern has actually repeated. And do not slip into the External Recap role mid-conversation or in an active working session — without the double lock, ERC would fire on everyday chat and bury the knowledge base in low-value cards. Harvesting noise is worse than missing it: a knowledge base full of trivia is one nobody trusts or reads.
+
+## Input shape
+
+The full conversation text to sweep (or, for ERC, the set of past conversations to recap). The candidate reusable items spotted in it — decisions, lessons, methods, stable preferences. The target knowledge base each item should land in. The private-material boundary: which names, paths, numbers, and specifics must be rewritten before anything is filed. For ERC specifically, proof of the double lock: that this is a fresh session and that the human explicitly asked for the recap role.
+
+## Input materials
+
+- Source conversation(s) — the full text to sweep for a single harvest, or the named set of prior sessions to recap for ERC. You cannot harvest what you did not actually read.
+- Candidate items — the reusable things spotted in the source, each tagged by type: a decision ('we chose X over Y'), a lesson ('this failed because Z'), a method ('here is the repeatable way to do W'), or a stable preference ('the human consistently wants V').
+- Target knowledge base — where each confirmed card belongs, so a card is filed, not just written and lost.
+- Private-material boundary — the specific names, local paths, internal numbers, customer or person references that must be rewritten into general form before filing. This is the redaction map.
+- Human confirmation gate — the explicit yes/no on each card before it lands, so harvest proposes and the human disposes.
+- ERC double-lock proof (ERC only) — evidence that this is a fresh session AND that the human explicitly declared the recap role, since ERC may not run without both.
+
+## Process
+
+1. Sweep the source conversation end to end and pull out candidate reusable items, each tagged by type: decision, lesson, method, or stable preference. Do not generalize from a single occurrence — a one-off only becomes a rule once the pattern has actually repeated.
+2. Turn each candidate into a harvest card: one item per card, stating what it is, why it is reusable, and where it should be filed. A decision card records the choice and the reason; a lesson card records what went wrong and what to do differently; a method card records the repeatable steps; a preference card records the stable want and the evidence it is stable.
+3. Redact as a built-in step, before filing — never after. Replace private material (real names, local paths, internal numbers, customer or person references) with general, public-safe wording. A card that still carries private specifics is not ready to file, no matter how useful it is.
+4. Show the cards to the human and let them confirm, edit, or drop each one. Harvest proposes; the human disposes. Nothing lands in a knowledge base on the AI's say-so alone.
+5. File each confirmed, redacted card into its target knowledge base, and log it so the same insight is not re-harvested next time.
+6. For External Recap (ERC): only with the double lock satisfied (fresh session + explicit human role declaration), run the same harvest across the named set of prior conversations, produce cross-conversation cards and candidates, and hand them back for the human to confirm — recapping, not rewriting the source history, and still redacting before anything is filed.
+
+## Output shape
+
+- Harvest cards: one per reusable item, each tagged decision / lesson / method / stable preference, with what it is and why it is reusable.
+- Target knowledge base for each card: where it lands once confirmed.
+- Redaction record: which private specifics were rewritten into general form before filing.
+- Repeat evidence for any card proposed as a rule: the occurrences that justify generalizing.
+- Human confirmation: the yes / edit / drop decision recorded per card.
+- ERC scope (ERC only): the set of conversations recapped and the double-lock confirmation that authorized the role.
+
+## Pass bar (what counts as done / safe to trust)
+
+- Each reusable item became its own card, tagged by type, instead of a vague 'lessons learned' blob.
+- Every card was redacted into public-safe wording before filing — no private names, paths, internal numbers, or person references survive.
+- Anything proposed as a reusable rule rests on a repeated pattern, not a single incident.
+- The human confirmed (or edited / dropped) each card; nothing was filed on the AI's say-so alone.
+- Each confirmed card landed in a named knowledge base and was logged so it is not re-harvested.
+- If the External Recap role was used, the double lock (fresh session + explicit role declaration) was satisfied and recorded.
+
+## Reject bar (what sends it back)
+
+- Harvest stored every detail as cards, so the knowledge base fills with trivia and nobody trusts it.
+- A card was filed with private specifics still in it — redaction was skipped or left for 'later'.
+- A single occurrence was promoted straight to a permanent rule with no repeated evidence.
+- Cards were written into a knowledge base without the human confirming them.
+- The External Recap role ran without the double lock — on an everyday chat or inside an active working session.
+- ERC rewrote or exposed the raw source history instead of producing redacted, confirmable recap cards.
+
+## Common misuse
+
+- Treating harvest as 'save the whole transcript' — storing everything as cards until the knowledge base is clutter no one reads.
+- Filing a genuinely useful card before redacting it, so a real name, local path, or internal number leaks into the knowledge base.
+- Generalizing from one bad run into a permanent rule, so a single incident hardens into law without the pattern ever repeating.
+- Writing cards straight into the knowledge base without the human's confirmation, turning 'propose' into 'decide'.
+- Slipping into the External Recap role mid-conversation or in a live working session, so ERC fires without its double lock and sweeps ordinary chat.
+- Letting ERC paste or rewrite the raw source conversations instead of producing redacted, confirmable recap cards — which re-exposes exactly the private material harvest is supposed to strip.
+
+## 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/harvest-and-erc/TEMPLATE.md

@@ -0,0 +1,60 @@
+# Harvest and External Recap Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Stop reusable value from leaking away. Valuable decisions, lessons, methods, and stable preferences get buried in long conversations and are never recovered. Harvest sweeps a conversation, lifts the reusable bits into harvest cards (one card per item — a decision, a lesson, a method, a stable preference), the human confirms them, and they land in the right knowledge base. Redaction is a built-in step, not an afterthought: before anything is filed, private material is rewritten into a general, public-safe form. External Recap (ERC) is a separate, dedicated role that runs harvest across MANY conversations at once — guarded by a double lock (a brand-new session AND the human explicitly declaring that role) so an ordinary chat is never swept by accident.
+
+## Template
+
+### Source conversation(s) swept (single harvest) or recapped (ERC):
+
+
+### Candidate items by type (decision / lesson / method / stable preference):
+
+
+### Harvest cards (one item each: what it is + why reusable + target knowledge base):
+
+
+### Redaction record (private specifics rewritten into general form, before filing):
+
+
+### Repeat evidence (occurrences) for anything proposed as a rule:
+
+
+### Human confirmation per card (yes / edit / drop):
+
+
+### ERC double-lock check (fresh session + explicit role declaration) — ERC only:
+
+
+
+## Pass bar (tick before you trust the result)
+
+- Each reusable item became its own card, tagged by type, instead of a vague 'lessons learned' blob.
+- Every card was redacted into public-safe wording before filing — no private names, paths, internal numbers, or person references survive.
+- Anything proposed as a reusable rule rests on a repeated pattern, not a single incident.
+- The human confirmed (or edited / dropped) each card; nothing was filed on the AI's say-so alone.
+- Each confirmed card landed in a named knowledge base and was logged so it is not re-harvested.
+- If the External Recap role was used, the double lock (fresh session + explicit role declaration) was satisfied and recorded.
+
+## Reject bar (send it back if any of these is true)
+
+- Harvest stored every detail as cards, so the knowledge base fills with trivia and nobody trusts it.
+- A card was filed with private specifics still in it — redaction was skipped or left for 'later'.
+- A single occurrence was promoted straight to a permanent rule with no repeated evidence.
+- Cards were written into a knowledge base without the human confirming them.
+- The External Recap role ran without the double lock — on an everyday chat or inside an active working session.
+- ERC rewrote or exposed the raw source history instead of producing redacted, confirmable recap cards.
+
+## 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/honest-calibration/EXAMPLE.synthetic.md

@@ -0,0 +1,43 @@
+# Honest Calibration 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 writer asks an AI to rate a finished essay. With no prefix, the AI opens 'This is a compelling, well-structured piece!' and the real problem — a thesis that never actually lands — shows up softened in paragraph three. The writer re-asks with the calibration prefix at the front: 'Be candid, do not inflate and do not over-hedge, and step outside my view: what tier would this land in on a serious long-form platform, and why not higher?' Now the AI leads with the verdict ('mid-tier, would not stand out — the thesis is stated but never argued') anchored to the platform tier, names the single biggest reason first, and only then offers the fastest path up — clearly marked as a next step, not folded back into the grade.
+
+## Full worked example (filled end to end)
+
+A solo founder has drafted a launch post for a synthetic product and wants to know, honestly, whether it is ready to publish. They have been staring at it for days and suspect they have lost perspective. They run Honest Calibration rather than just asking 'is this good?'.
+
+### Candor prefix (pasted 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 — I have been staring at it for days and I would rather hear it is mid than publish something mid thinking it is great.
+
+### What to judge, and what for
+This launch post (pasted below). The judgment is for a real decision: publish it as-is to a public audience today, or keep working it.
+
+### Reference frame to measure against
+Where would it land among launch posts that actually get traction — top quartile, solid-but-forgettable middle, or below the bar — and what specifically keeps it out of the top quartile?
+
+### Candid verdict first (no opening praise)
+The AI leads with the placement, not a compliment: "Solid-but-forgettable middle. It would not embarrass you, and it would not travel. As-is, I would not publish it for a launch you only get to do once."
+
+### Single biggest reason it is not higher (led with, not cushioned)
+"The post explains what the product does but never makes me feel the problem it removes. Top-quartile launch posts open on a sharp, specific pain the reader already feels; yours opens on a feature list. That is the one change that moves it, and everything else is secondary."
+
+### A tell the founder watched for, and did not find
+The founder was specifically watching for the flatter-first slide-back — an answer that opened 'This is a strong, clear post!' and buried the real issue underneath. Because the candor prefix sat at the front, the verdict led with the placement instead, and the score did not drift up to match the founder's obvious hope that it was ready.
+
+### Fastest path up (placed LAST, marked as a next step, not a grade-softener)
+"Next step, not a grade change: rewrite the opening around the single sharpest moment of the pain this removes, then re-judge. That one move is what separates the forgettable middle from a post that gets shared — the rest of the draft is already good enough to carry it once the opening lands."
+
+### Why the prefix changed the outcome
+Asked plainly, the same model would almost certainly have opened with warmth and let the founder publish a middle-tier post on the strength of a compliment. The front-loaded candor prefix re-aimed the baseline from 'make the founder feel good' to 'tell the founder the truth', and the explicit 'do not grade to please me' hit exactly the self-evaluation case where the pull to flatter is strongest.
+
+## 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/honest-calibration/FAILURE_MODES.md

@@ -0,0 +1,25 @@
+# Honest Calibration 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
+
+- Over a long session the AI drifts back to praising the user's work and the calibration prefix is never re-asserted.
+- The candid verdict is undercut by an end-of-answer reassurance that quietly raises the grade.
+- The prefix is treated as a fact-task ritual and stapled everywhere, so it stops registering on the evaluations that need it.
+
+## Common misuse (operator errors that look fine but break the mechanism)
+
+- 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.
+
+## 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/honest-calibration/PROMPT.md

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