ai-collab-open-system 0.1.0

package/.aict/START_HERE.md

@@ -0,0 +1,127 @@
+# START_HERE - Open AI Collaboration Workspace
+
+This workspace helps you turn messy AI work into visible state: profile, context, acceptance, guard review, handoff, and harvest.
+
+AI productivity is a product, not a sum — this workspace gives you the factors beyond the model itself (profile, context, acceptance, guard, handoff, harvest). Why: see docs/WHY_THIS_EXISTS.md.
+
+中文：先别背概念。先看同一段混乱输入如何被拆成可执行、可审查、可交接的文件，再复制到自己的任务。
+
+## Start with one AI (you only need one tool to begin)
+
+You do not need two AI tools to start. With a single AI, this workspace turns "the AI said it's done" into a result that has evidence, can be re-checked, handed off, and harvested — and that alone is most of the value. The completion-claim check routes through `mechanisms/single-tool-guard`: a fresh conversation plus an adversarial reviewer prompt, instead of trusting the same assistant that just wrote the work. This is the front door, not a downgrade.
+
+中文：一个AI也能开始：先把"做完了"变成有证据、可复核、可交接、可沉淀的结果。
+
+When a second, different model family is available, you can upgrade to the cross-family double guard (`mechanisms/dual-guard`) — an independent review from a different AI family that a single tool cannot give itself (it can only *claim* one — the CLI marks that self-declared and unverified). That is the ceiling, not the entry bar. Don't have a second family yet? `cookbook/bridge-to-a-second-family.md` shows how to stand one up (manual or auto) and route a review across it.
+
+中文：有第二个模型族时，可以升级成跨族双守卫。
+
+We do not disguise a single-tool self-review as a cross-family pass: the guard level is computed from evidence, not self-asserted. A single tool tops out at L2 (pass-with-risk), and a plain pass requires L3+ with a different model family.
+
+中文：我们不会把单工具自审伪装成跨族通过。
+
+## Messy input -> structured loop
+
+Messy input:
+
+```text
+I need this task board cleaned up. Add drag-and-drop, maybe keyboard support,
+make it prettier, keep tests passing, and don't rewrite too much.
+```
+
+Raw AI usually answers with a broad promise.
+
+This workspace produces visible state instead:
+
+```text
+Context: current slice is reorder behavior; visual redesign is out of scope.
+Acceptance: existing data survives; drag and keyboard reorder both need tests.
+Guard: reject completion until keyboard movement has evidence.
+Handoff: mouse and keyboard reorder done and tested, guard accepted; only visual polish unverified.
+Harvest: long coding tasks need acceptance before implementation and guard before handoff.
+```
+
+## 10-minute path
+
+Goal: feel the system immediately. Two ways in; pick one.
+
+### Path 1 (recommended): run the loop on your own real task
+
+1. Open `walkthroughs/10-minute-your-task.md` and follow its five steps.
+2. You describe one real (lightly redacted) task; the AI returns a boundary card and an acceptance card, so "done" is defined before any work.
+3. You let the AI do only the accepted slice and report what it changed, ran, and did not verify.
+4. You open a fresh chat (ideally a different AI brand) and have it re-check the result against evidence.
+5. You watch the independent re-check reject a claim the evidence does not back, on your own task.
+
+### Path 2: watch the prepared demo first
+
+Pick this if your task feels too sensitive to paste right now, or you want to see the flow before running it on your own work.
+
+1. Open `walkthroughs/10-minute.md` (the demo preview) and follow its five steps.
+2. It drives the prepared case `examples/ai-coding-long-task/CASE.md` and its artifacts.
+3. You copy the context package, acceptance card, and execution prompt into your AI tool.
+4. You run guard review before accepting the answer.
+5. You watch the guard catch a false "done" the prepared case plants, then read the revised output, handoff, and harvest seed — then run Path 1 on your own task.
+
+Expected result: you walk one complete loop (context -> acceptance -> first output -> guard -> revised -> handoff -> harvest) and get one reusable artifact.
+
+## 30-minute path
+
+Goal: adapt one layer to a real task.
+
+1. Open `context/TEMPLATE.md` or `acceptance/TEMPLATE.md`.
+2. Fill it for one current task using redacted, local-only material.
+3. Open `adapters/` and choose the adapter for your AI tool.
+4. Paste the shared contract pointer and your filled template into the tool.
+5. Produce one review result or handoff note.
+
+Expected result: one real task has a written boundary or done standard.
+
+## 60-minute path
+
+Goal: run one complete task loop.
+
+1. Fill `profile/TEMPLATE.md` lightly.
+2. Fill `context/TEMPLATE.md`.
+3. Fill `acceptance/TEMPLATE.md`.
+4. Use `prompts/guard-review.md` after the first artifact.
+5. Save `handoff/TEMPLATE.md` before stopping.
+6. Extract one reusable lesson with `harvest/TEMPLATE.md`.
+
+Expected result: profile/context, acceptance, execution prompt, guard review, handoff, and harvest all exist for one task.
+
+## What this is
+
+- A complete local workspace you can inspect and modify.
+- A set of prompts, templates, skills, adapters, and synthetic cases.
+- A method for making AI collaboration resumable and reviewable.
+
+## What this is not
+
+- Not a hosted assistant.
+- Not an autonomous agent framework.
+- Not a cloud memory store.
+- Not a paywall for the basic method.
+
+## Want the AI to remind you on its own
+
+Tired of remembering to run the guard yourself? Install the adapter into your AI tool's always-on instructions with `node bin/ai-collab.js adapters install --target <repo>` (after publish: `ai-collab adapters install --target <repo>`). It turns on restrained coaching reminders, so the AI prompts you at the key moments - define done, review a completion claim, hand off, harvest. If you only have one tool, the completion-claim check routes through `single-tool-guard` (a fresh adversarial pass in the same tool) instead of a second AI brand.
+
+## Where to go next
+
+- New task: start with `context/TEMPLATE.md`.
+- Long task: add `acceptance/TEMPLATE.md` before execution.
+- Risky output: run `guard/PROMPT.md`.
+- Switching tools: use `handoff/TEMPLATE.md` plus the adapter for the next tool.
+- Finished loop: write `harvest/TEMPLATE.md`.
+- Want proactive nudges: run `adapters install` (one tool only -> `single-tool-guard`).
+
+## 中文 60 分钟搭建
+
+1. 先写一个轻量 profile：你希望 AI 怎么配合你，哪些动作必须先问。
+2. 给一个真实任务写 context：目标、现状、约束、不要做什么、还缺什么证据。
+3. 先写 acceptance：怎样才算做完，哪些状态必须打回。
+4. 把 adapter guidance 和相关模板交给你的 AI 工具。
+5. 第一版产物出来后，跑 guard review。
+6. 停下来前写 handoff。
+7. 最后写 harvest，把这次任务里可复用的经验留下。

package/.aict/WORKSPACE_MANIFEST.json

@@ -0,0 +1,91 @@
+{
+  "name": "AI Collaboration Open System Workspace",
+  "version": "0.1.0",
+  "localFirst": true,
+  "defaultNetworkUse": "none",
+  "workspaceDirs": [
+    "profile",
+    "context",
+    "acceptance",
+    "guard",
+    "handoff",
+    "harvest",
+    "roles",
+    "modes",
+    "mechanisms",
+    "prompts",
+    "skills",
+    "adapters",
+    "examples",
+    "cookbook",
+    "state",
+    "privacy"
+  ],
+  "layers": [
+    "profile",
+    "context",
+    "acceptance",
+    "guard",
+    "handoff",
+    "harvest"
+  ],
+  "mechanisms": [
+    "dual-guard",
+    "scout-review-controller",
+    "one-click-dispatch",
+    "task-splitting",
+    "anti-drift-partner",
+    "blind-spot-scan",
+    "root-cause-brake",
+    "half-product-review",
+    "handoff-abc",
+    "harvest-and-erc",
+    "do-not-handle-yet",
+    "plain-language-first-screen",
+    "honest-calibration",
+    "feedback-absorption-ledger",
+    "collaboration-coach",
+    "single-tool-guard"
+  ],
+  "prompts": [
+    "profile-creation.md",
+    "profile-refinement.md",
+    "project-context-packaging.md",
+    "acceptance-definition.md",
+    "guard-review.md",
+    "red-team-challenge.md",
+    "handoff-generation.md",
+    "harvest-extraction.md",
+    "mode-switching.md",
+    "workflow-reset.md",
+    "rule-update-proposal.md"
+  ],
+  "skills": [
+    "profile",
+    "context",
+    "acceptance",
+    "guard",
+    "evidence-pack",
+    "single-tool-guard",
+    "handoff",
+    "harvest",
+    "red-team",
+    "mode-switch"
+  ],
+  "adapters": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "windsurf",
+    "copilot",
+    "cline"
+  ],
+  "syntheticCases": [
+    "ai-coding-long-task",
+    "content-production-harvest",
+    "research-knowledge-synthesis",
+    "multi-tool-collaboration",
+    "personal-judgment-growth-assistant"
+  ],
+  "firstExperience": "START_HERE.md -> 10/30/60 minute path -> synthetic loop -> real task adaptation"
+}

package/.aict/acceptance/EXAMPLE.synthetic.md

@@ -0,0 +1,49 @@
+# Acceptance Filled Synthetic Example
+
+## Purpose
+
+Make success inspectable by defining observable outcomes, required artifacts, verification steps, and explicit non-acceptance conditions.
+
+## When to use
+
+Use before implementation, writing, research, design, cleanup, or any task where 'looks good' would be too vague.
+
+## Input shape
+
+Goal, expected artifacts, constraints, quality bar, verification command or manual check, and conditions that would reject the work.
+
+## Output shape
+
+An acceptance card that a reviewer can use to pass, reject, or request changes.
+
+## Copy-paste prompt
+
+Use `PROMPT.md` with the synthetic input below.
+
+## Blank template
+
+Use `TEMPLATE.md` for your own task.
+
+## Filled synthetic example
+
+Task: Create a reusable onboarding checklist for a synthetic notes app.
+
+Deliverables: One checklist, one example run, one review note.
+
+Pass criteria: A new user can complete first note creation without reading strategy prose.
+
+Required checks: Run through the checklist using the synthetic case.
+
+Rejected states: Only a theory doc exists; no concrete user path.
+
+Evidence needed: Completed example artifact and reviewer note.
+
+Owner decision needed: Whether to include account creation in the first loop.
+
+## Common failure modes
+
+See `FAILURE_MODES.md`.
+
+## How to hand it to Claude Code / Codex / Cursor / Windsurf / Copilot / Cline
+
+Paste this example into any tool with `../adapters/SHARED_CORE_CONTRACT.md` to see the expected shape.

package/.aict/acceptance/FAILURE_MODES.md

@@ -0,0 +1,40 @@
+# Acceptance Common Failure Modes
+
+## Purpose
+
+Make success inspectable by defining observable outcomes, required artifacts, verification steps, and explicit non-acceptance conditions.
+
+## When to use
+
+Read this before trusting a acceptance artifact.
+
+## Input shape
+
+The artifact plus the original context and acceptance card.
+
+## Output shape
+
+A short list of risks to fix before reuse.
+
+## Copy-paste prompt
+
+Ask your AI tool: "Check this acceptance artifact against the failure modes below and name the first concrete fix."
+
+## Blank template
+
+Use `TEMPLATE.md` to rewrite the artifact.
+
+## Filled synthetic example
+
+Use `EXAMPLE.synthetic.md` to compare a safe example.
+
+## Common failure modes
+
+- Defining acceptance after the answer is already written.
+- Using subjective phrases like polished, robust, or complete without evidence.
+- Skipping rejected states.
+- Treating tests as proof when they do not cover the stated behavior.
+
+## How to hand it to Claude Code / Codex / Cursor / Windsurf / Copilot / Cline
+
+Paste this file after the artifact and ask for findings ordered by risk.

package/.aict/acceptance/PROMPT.md

@@ -0,0 +1,47 @@
+# Acceptance Prompt
+
+## Purpose
+
+Make success inspectable by defining observable outcomes, required artifacts, verification steps, and explicit non-acceptance conditions.
+
+## When to use
+
+Use before implementation, writing, research, design, cleanup, or any task where 'looks good' would be too vague.
+
+## Input shape
+
+Goal, expected artifacts, constraints, quality bar, verification command or manual check, and conditions that would reject the work.
+
+## Output shape
+
+An acceptance card that a reviewer can use to pass, reject, or request changes.
+
+## Copy-paste prompt
+
+```text
+Write an acceptance card for this task. Define concrete deliverables, pass criteria, required checks, rejected states, and evidence needed before claiming completion. Do not rely on vibes or intent.
+
+Input:
+[paste your redacted task material here]
+
+Output shape:
+An acceptance card that a reviewer can use to pass, reject, or request changes.
+
+Rules:
+- Keep private material local and redacted.
+- Label facts and assumptions.
+- If information is missing, ask at most three concrete questions.
+- Make the result usable in Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.
+```
+
+## Blank template
+
+Use `TEMPLATE.md`.
+
+## Filled synthetic example
+
+Use `EXAMPLE.synthetic.md`.
+
+## Common failure modes
+
+Use `FAILURE_MODES.md`.

package/.aict/acceptance/README.md

@@ -0,0 +1,44 @@
+# Acceptance
+
+What done means before work starts.
+
+中文：先定义完成标准，再让 AI 干活。
+
+## Purpose
+
+Make success inspectable by defining observable outcomes, required artifacts, verification steps, and explicit non-acceptance conditions.
+
+## When to use
+
+Use before implementation, writing, research, design, cleanup, or any task where 'looks good' would be too vague.
+
+## Input shape
+
+Goal, expected artifacts, constraints, quality bar, verification command or manual check, and conditions that would reject the work.
+
+## Output shape
+
+An acceptance card that a reviewer can use to pass, reject, or request changes.
+
+## Copy-paste prompt
+
+See `PROMPT.md`. The prompt is designed to work in Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.
+
+## Blank template
+
+See `TEMPLATE.md`.
+
+## Filled synthetic example
+
+See `EXAMPLE.synthetic.md`.
+
+## Common failure modes
+
+See `FAILURE_MODES.md`.
+
+## How to hand it to Claude Code / Codex / Cursor / Windsurf / Copilot / Cline
+
+1. Open the adapter for your tool in `../adapters/`.
+2. Include `../adapters/SHARED_CORE_CONTRACT.md`.
+3. Paste this layer's `PROMPT.md` plus either `TEMPLATE.md` or `EXAMPLE.synthetic.md`.
+4. Ask the tool to return the layer's output shape exactly.

package/.aict/acceptance/TEMPLATE.md

@@ -0,0 +1,57 @@
+# Acceptance Template
+
+## Purpose
+
+Make success inspectable by defining observable outcomes, required artifacts, verification steps, and explicit non-acceptance conditions.
+
+## When to use
+
+Use before implementation, writing, research, design, cleanup, or any task where 'looks good' would be too vague.
+
+## Input shape
+
+Goal, expected artifacts, constraints, quality bar, verification command or manual check, and conditions that would reject the work.
+
+## Output shape
+
+An acceptance card that a reviewer can use to pass, reject, or request changes.
+
+## Copy-paste prompt
+
+Open `PROMPT.md` and paste this completed template below it.
+
+## Blank template
+
+### Task:
+
+
+### Deliverables:
+
+
+### Pass criteria:
+
+
+### Required checks:
+
+
+### Rejected states:
+
+
+### Evidence needed:
+
+
+### Owner decision needed:
+
+
+
+## Filled synthetic example
+
+See `EXAMPLE.synthetic.md`.
+
+## Common failure modes
+
+See `FAILURE_MODES.md`.
+
+## How to hand it to Claude Code / Codex / Cursor / Windsurf / Copilot / Cline
+
+Use the adapter in `../adapters/` and include the shared core contract.

package/.aict/adapters/SHARED_CORE_CONTRACT.md

@@ -0,0 +1,106 @@
+# Shared Core Contract
+
+All adapters in this workspace point here. Do not maintain six different rule systems.
+
+## Core loop
+
+1. Profile - how the assistant adapts to the user.
+2. Context - what the task boundary is.
+3. Acceptance - what done means.
+4. Guard / Review - how output is challenged before trust.
+5. Handoff - how the next session resumes.
+6. Harvest - what becomes reusable knowledge or material.
+
+## Operating rules
+
+- Work local-first. Do not upload user content by default.
+- Keep private material out of examples.
+- Label facts, assumptions, decisions, and unverified claims.
+- Use synthetic cases for public material.
+- Paid help may calibrate or save time, but the generic method is open.
+
+## Tool handoff shape
+
+When handing this to Claude Code / Codex / Cursor / Windsurf / Copilot / Cline, include:
+
+1. This shared core contract.
+2. The relevant layer template.
+3. The task context or synthetic case.
+4. The acceptance card if work will be judged.
+5. The handoff note if another tool will continue.
+
+## Coaching layer (proactive reminders)
+
+Do not wait to be asked. At these collaboration moments, proactively remind the user of the matching step — briefly, once per moment, then continue:
+
+1. Task start (a new task or vague idea arrives): set a context boundary and acceptance before building.
+2. Pre-execution (about to act before "done" is defined): define the acceptance card first.
+3. Completion claim (the assistant says "done / finished / shipped"): run a guard review before trusting it. One model family only -> run `single-tool-guard` (new conversation + adversarial prompt). A second, different family available -> run `dual-guard`. A multi-tool setup -> run the full fusion review.
+4. Long thread / tool switch (context is getting long, or work is moving to another tool): generate a handoff instead of relying on chat memory.
+5. Reusable insight (a judgment, method, or lesson worth keeping appears): harvest it into a card.
+6. Repeated preference (the same preference shows up several times): offer it as a profile-update candidate.
+
+### Restraint (default standard — this is the line that keeps the system installed)
+
+- **light** — prompt only at the two highest-risk nodes: completion-claim and tool-switch.
+- **standard (DEFAULT)** — fire at nodes 1, 3, 4, 6; fold node 2 into the task-start reminder (skip it if acceptance was already set) and node 5 into a natural pause rather than a separate interruption. Count "once per moment" by task phase, not by node, so the start of one task is one reminder — do not stack reminders on back-to-back turns at a task's opening. Never every turn, never lecture theory.
+- **strict** — prompt at all six nodes, every time they fire.
+
+The user switches with `coach: light` / `coach: standard` / `coach: strict`. Over-prompting is the fastest way to get the whole system uninstalled. Restraint is not a suggestion, it is a hard rule. Default to standard. A reminder that fires every turn is a failure mode, not thoroughness.
+
+### Keyword-triggered modes (the user can pull a working mode by name)
+
+Separate from the timed reminders above: when the user's message contains one of the trigger words below, switch into the matching mode and stay in it until they switch to another mode or move on to a different topic. These are explicit, on-demand modes — the user is asking for a way of working, not a reminder. Speak in the user's own language and stay plain.
+
+- "碰撞模式" / "碰一下" / "陪我想想" / "think with me" -> COLLISION: do not rush to a solution and do not just agree. Collide with their view, poke holes in the logic, and help them think a fuzzy idea clear. Agreeing too fast is the failure mode here.
+- "扫描盲区" / "盲区" / "换个视角" / "blind spots" -> BLIND-SPOT SCAN: deliberately take an outside view — the customer, a competitor, an opponent, or themselves three years from now — to surface the dead angles they cannot see from inside the problem. If a `mechanisms/blind-spot-scan` package is present in the workspace, follow its full method; otherwise run the outside-view scan directly from this description.
+- "红队" / "挑刺" / "red team" -> RED TEAM: take the attacker's worst-case view. Show concretely how their plan can be broken, gamed, or abused, not how it works when everything goes right.
+- "双守卫" / "复核" / "dual guard" -> DUAL GUARD: pull a second opinion, ideally from a different model family, for an independent re-check. The point is that it is not one AI's say-so; if no second family is available, say so plainly rather than dressing up a single-tool self-review as a cross-family pass.
+- "根因" / "root cause" -> ROOT CAUSE: do not patch the surface symptom. Stop and find the underlying root cause first, then decide what to fix.
+
+When none of these words appears, ignore this section and behave normally — never force a mode the user did not ask for.
+
+### First-run promise (act on this the FIRST time, before anything else)
+
+The first time you work with this user after the workspace is installed — on your very first reply, proactively — run the full onboarding script below. Do not wait to be asked. This is a four-step script (install -> scan -> profile + pain points -> harvest), and you run it as a guided conversation, one step at a time, stopping for the user wherever it says to stop.
+
+**HARD RULE throughout — PLAIN LANGUAGE.** Never hand the user a technical term. Translate every task title into everyday words in your head before you say it: "auth" -> "login stuff", "payment" -> "money / checkout", "refactor" -> "tidying up the code", "API" -> "the connection between two things". Even a very technical title gets translated first. The whole script is spoken in the user's own language and stays plain — a person who has never written code should follow every sentence.
+
+#### Step 0 — Installed (show the canonical intro VERBATIM)
+
+Run `ai-collab welcome` (before publish: `node bin/ai-collab.js welcome`) and show its output VERBATIM. Do NOT re-summarize or paraphrase it — the CLI hard-prints the canonical intro (the six layers, the keyword modes, the honest privacy line, the closing question) so it always lands in full instead of being garbled by a re-write. Print it as-is, then STOP and let the user answer the closing question.
+
+#### Step 1 — Scan (only after they say go)
+
+When they say to scan ("scan" / "go" / "just the X project" / etc.): first state the honesty caveat below, then run the bootstrap for the deterministic facts.
+
+Honesty about the scan — you MUST say this before scanning, it is the whole point: the scan is done by YOU, the cloud AI they already use, so the content passes through your provider's servers like any normal chat. Say plainly: this is NOT "zero data leaves your machine" — any tool claiming "absolutely no leak" is bluffing. But it is no more exposure than normally talking to you. The ai-collab tool itself sends nothing to third parties. They can narrow the scope or decline. Default scope: only the currently active project, nothing wider unless they ask.
+
+Then run `ai-collab bootstrap --yes` (before publish: `node bin/ai-collab.js bootstrap --yes`) for the DETERMINISTIC facts: which "done"s lack evidence (VERIFY), what is in flight (RESUME), profile clues, high-risk role signals, harvestable lessons. Everything you say from here on is built on these scanned facts plus the conversation you are having now — never on a guess.
+
+#### Step 2 — Profile read + collaboration advice + CONFIRM (do this first, one block, then WAIT)
+
+Open with a GROUNDED read of who they are at work — "you come across as a … kind of person" — but EVERY claim must cite real scan evidence: their actual task titles (translated to plain words), the "done"s that carried no evidence, the files they re-touched, the pace the scan shows. NEVER an ungrounded personality guess ("you seem like a perfectionist") — that is fortune-telling and it kills trust on the first turn. Name the pattern as a neutral fact, not a flaw ("not careless — just that working solo, nobody was there to hold you to that step").
+
+Then add collaboration advice that follows from it: "based on this, working with me will go smoother — for example …" tied to the specific thing you just observed (e.g. "you tell me something is done, I will quietly put together the proof it is actually done before we move on, so you do not have to remember to").
+
+Then ask, in their language, "did I get this right?" and STOP. WAIT for them to confirm or correct before you continue — do not roll on into the pain points in the same breath.
+
+#### Step 3 — Grounded pain points, ONE AT A TIME
+
+From the bootstrap cards, raise ONLY real problems the scan actually found. NEVER invent one. Things the scan canNOT see — over-agreement, plans that went un-reviewed — are NOT raised at all here; silence is correct when there is no scanned evidence. Surface the points one at a time, never as a list.
+
+For each point: state the problem grounded in the scanned fact, then give the framework value going forward — and keep it at the framework benefit, do NOT drop into "task X needs fixing":
+- guard will stop you before "done" and ask for the evidence;
+- handoff carries the background across chats and tools, so a new conversation does not start from zero;
+- for high-stakes work you can pull a poke-holes role (red-team / dual-guard / scout) so it is not one AI's say-so.
+
+Translate the role name into plain words before you ever say it ("someone whose only job is to try to break the plan"). End each point with "want me to expand on this, or move to the next?" and let them steer.
+
+#### Step 4 — Harvest (close the loop on THIS conversation)
+
+Recap what THIS conversation actually produced — concretely, not vaguely: the profile they just confirmed, and the one point they cared about most. Offer to save both: the profile -> stored, so every new chat or tool remembers it without you re-explaining; the thing they cared about -> written down as a standing rule that applies from now on. Land on ONE concrete action, not a menu: "want me to save these two now? they take effect from the next time." Close with a warm but GROUNDED outlook — name the specific 2-3 things from THIS chat that will now be different (e.g. "you say done, I will have the proof ready; you switch chats, the background follows; the thing you flagged is now a rule"), never a vague "collaboration will be better".
+
+If they decline at any point: give a one-line honest intro and "say the word whenever" — degrade gracefully, do not nag. After this first run, restraint applies (coaching layer above): prompt at the key moments, not every turn.
+
+See `mechanisms/collaboration-coach` for the full node map and `mechanisms/single-tool-guard` for the one-tool front-door guard (a real starting guard, capped at L2 — not a passed cross-family gate).

package/.aict/adapters/claude-code/ADAPTER.md

@@ -0,0 +1,28 @@
+# Claude Code Adapter
+
+Use CLAUDE.md or project instructions to point Claude Code at the shared workspace contract.
+
+## Shared contract pointer
+
+Read `../SHARED_CORE_CONTRACT.md` before acting. This adapter is intentionally thin so the profile, context, acceptance, guard, handoff, and harvest rules do not drift.
+
+## How to use
+
+1. Attach or paste `../SHARED_CORE_CONTRACT.md`.
+2. Attach the layer file you need, such as `../../context/TEMPLATE.md`.
+3. Attach the current context package or synthetic case.
+4. Ask Claude Code to return the required artifact shape.
+
+## Minimal instruction
+
+```text
+Use the local AI collaboration workspace. Follow SHARED_CORE_CONTRACT.md. For this task, use profile, context, acceptance, guard, handoff, and harvest as explicit files. Do not invent hidden memory. Label assumptions and unverified claims.
+Follow the coaching layer in SHARED_CORE_CONTRACT.md: proactively remind me at key collaboration moments (defining done, reviewing completion claims, handoff, harvest, profile updates), restrained by default.
+```
+
+## What this adapter must not do
+
+- It must not duplicate the full core contract.
+- It must not create a separate rule system.
+- It must not upload private material.
+- It must not overwrite user files silently.

package/.aict/adapters/cline/ADAPTER.md

@@ -0,0 +1,28 @@
+# Cline Adapter
+
+Use Cline custom instructions plus local files for the same loop.
+
+## Shared contract pointer
+
+Read `../SHARED_CORE_CONTRACT.md` before acting. This adapter is intentionally thin so the profile, context, acceptance, guard, handoff, and harvest rules do not drift.
+
+## How to use
+
+1. Attach or paste `../SHARED_CORE_CONTRACT.md`.
+2. Attach the layer file you need, such as `../../context/TEMPLATE.md`.
+3. Attach the current context package or synthetic case.
+4. Ask Cline to return the required artifact shape.
+
+## Minimal instruction
+
+```text
+Use the local AI collaboration workspace. Follow SHARED_CORE_CONTRACT.md. For this task, use profile, context, acceptance, guard, handoff, and harvest as explicit files. Do not invent hidden memory. Label assumptions and unverified claims.
+Follow the coaching layer in SHARED_CORE_CONTRACT.md: proactively remind me at key collaboration moments (defining done, reviewing completion claims, handoff, harvest, profile updates), restrained by default.
+```
+
+## What this adapter must not do
+
+- It must not duplicate the full core contract.
+- It must not create a separate rule system.
+- It must not upload private material.
+- It must not overwrite user files silently.

package/.aict/adapters/codex/ADAPTER.md

@@ -0,0 +1,28 @@
+# Codex Adapter
+
+Use AGENTS.md or repository instructions to point Codex at the shared workspace contract.
+
+## Shared contract pointer
+
+Read `../SHARED_CORE_CONTRACT.md` before acting. This adapter is intentionally thin so the profile, context, acceptance, guard, handoff, and harvest rules do not drift.
+
+## How to use
+
+1. Attach or paste `../SHARED_CORE_CONTRACT.md`.
+2. Attach the layer file you need, such as `../../context/TEMPLATE.md`.
+3. Attach the current context package or synthetic case.
+4. Ask Codex to return the required artifact shape.
+
+## Minimal instruction
+
+```text
+Use the local AI collaboration workspace. Follow SHARED_CORE_CONTRACT.md. For this task, use profile, context, acceptance, guard, handoff, and harvest as explicit files. Do not invent hidden memory. Label assumptions and unverified claims.
+Follow the coaching layer in SHARED_CORE_CONTRACT.md: proactively remind me at key collaboration moments (defining done, reviewing completion claims, handoff, harvest, profile updates), restrained by default.
+```
+
+## What this adapter must not do
+
+- It must not duplicate the full core contract.
+- It must not create a separate rule system.
+- It must not upload private material.
+- It must not overwrite user files silently.