ai-collab-open-system 0.1.0

package/.aict/profile/EXAMPLE.synthetic.md

@@ -0,0 +1,49 @@
+# Profile Filled Synthetic Example
+
+## Purpose
+
+Capture stable collaboration preferences that affect how an assistant should ask, decide, challenge, summarize, and hand work back.
+
+## When to use
+
+Use before long tasks, recurring work, cross-tool handoffs, or any situation where tone, risk appetite, and decision rules matter.
+
+## Input shape
+
+A short description of the user's role, work type, preferred feedback style, constraints, review habits, and known failure patterns.
+
+## Output shape
+
+A compact profile card with preferences, hard boundaries, collaboration defaults, and update rules.
+
+## Copy-paste prompt
+
+Use `PROMPT.md` with the synthetic input below.
+
+## Blank template
+
+Use `TEMPLATE.md` for your own task.
+
+## Filled synthetic example
+
+User role or situation: Solo product builder validating a weekend prototype.
+
+Preferred collaboration style: Direct risk calls, short summaries, concrete next actions.
+
+Decision rules: Prefer evidence from user behavior over elegant architecture.
+
+Hard boundaries: Do not upload private notes or make purchasing decisions.
+
+Review habits: Wants assumptions and unverified claims labeled.
+
+Known failure patterns: Over-polished plans can replace real validation.
+
+How to update this profile: Add new stable preferences only after they appear in at least two tasks.
+
+## 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/profile/FAILURE_MODES.md

@@ -0,0 +1,40 @@
+# Profile Common Failure Modes
+
+## Purpose
+
+Capture stable collaboration preferences that affect how an assistant should ask, decide, challenge, summarize, and hand work back.
+
+## When to use
+
+Read this before trusting a profile 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 profile 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
+
+- Treating a profile as a personality essay instead of operational guidance.
+- Storing secrets, account details, or private identity signals.
+- Mixing task context into the stable profile and making future sessions stale.
+- Letting the assistant infer values without user confirmation.
+
+## 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/profile/PROMPT.md

@@ -0,0 +1,47 @@
+# Profile Prompt
+
+## Purpose
+
+Capture stable collaboration preferences that affect how an assistant should ask, decide, challenge, summarize, and hand work back.
+
+## When to use
+
+Use before long tasks, recurring work, cross-tool handoffs, or any situation where tone, risk appetite, and decision rules matter.
+
+## Input shape
+
+A short description of the user's role, work type, preferred feedback style, constraints, review habits, and known failure patterns.
+
+## Output shape
+
+A compact profile card with preferences, hard boundaries, collaboration defaults, and update rules.
+
+## Copy-paste prompt
+
+```text
+Create a profile card for this user. Extract only reusable collaboration preferences, not private secrets. Separate stable preferences from task-specific context. Return: working style, decision rules, communication preferences, hard boundaries, and what future assistants should ask before acting.
+
+Input:
+[paste your redacted task material here]
+
+Output shape:
+A compact profile card with preferences, hard boundaries, collaboration defaults, and update rules.
+
+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/profile/README.md

@@ -0,0 +1,44 @@
+# Profile
+
+How the AI adapts to the user's working style, constraints, and decision habits.
+
+中文：让 AI 先知道怎样配合这个人，而不是每次都按通用助理口吻开始。
+
+## Purpose
+
+Capture stable collaboration preferences that affect how an assistant should ask, decide, challenge, summarize, and hand work back.
+
+## When to use
+
+Use before long tasks, recurring work, cross-tool handoffs, or any situation where tone, risk appetite, and decision rules matter.
+
+## Input shape
+
+A short description of the user's role, work type, preferred feedback style, constraints, review habits, and known failure patterns.
+
+## Output shape
+
+A compact profile card with preferences, hard boundaries, collaboration defaults, and update rules.
+
+## 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/profile/TEMPLATE.md

@@ -0,0 +1,57 @@
+# Profile Template
+
+## Purpose
+
+Capture stable collaboration preferences that affect how an assistant should ask, decide, challenge, summarize, and hand work back.
+
+## When to use
+
+Use before long tasks, recurring work, cross-tool handoffs, or any situation where tone, risk appetite, and decision rules matter.
+
+## Input shape
+
+A short description of the user's role, work type, preferred feedback style, constraints, review habits, and known failure patterns.
+
+## Output shape
+
+A compact profile card with preferences, hard boundaries, collaboration defaults, and update rules.
+
+## Copy-paste prompt
+
+Open `PROMPT.md` and paste this completed template below it.
+
+## Blank template
+
+### User role or situation:
+
+
+### Preferred collaboration style:
+
+
+### Decision rules:
+
+
+### Hard boundaries:
+
+
+### Review habits:
+
+
+### Known failure patterns:
+
+
+### How to update this profile:
+
+
+
+## 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/prompts/acceptance-definition.md

@@ -0,0 +1,109 @@
+# Acceptance definition
+
+Purpose: Define observable pass criteria and required evidence before work starts.
+
+## Scenario
+
+Use before implementation, writing, research, cleanup, or review when 'looks good' would be too vague.
+
+## Input requirements
+
+- Task goal and expected artifact.
+- Quality bar and constraints.
+- Available verification commands or manual checks.
+- Rejected states that must not be accepted.
+
+## Operating steps
+
+1. Turn the goal into inspectable deliverables: name the file, the behavior, the output a skeptical reviewer could open and check. A deliverable you cannot point at is a deliverable you cannot accept.
+2. Write each pass criterion so it is mechanically checkable (a command that exits 0, a string that must appear, a behavior a stranger can reproduce), not a vibe like 'works well' or 'is clean'.
+3. Bind every completion claim to one of exactly three states and forbid any fourth: NOT DONE (nothing to show yet), DONE-PENDING-VERIFICATION (built but not yet proven), ACCEPTED (proven and signed off). Ban soft words like 'basically done', 'should be fine', 'mostly working' — they hide which state the work is really in.
+4. Require that any DONE-PENDING-VERIFICATION claim carry three-part evidence, and that the three parts are present before the claim counts: (1) WHAT CHANGED — file plus line plus a one-line description, specific enough that a reader sees the change in thirty seconds; (2) REAL COMMAND OUTPUT — the actual pasted text of grep -n / diff / wc -l / ls -la / the test run, not a verbal 'it is landed' or 'tests pass'; (3) WHAT IS NOT YET VERIFIED — the blind spots, edge cases, cross-file effects, and downstream dependencies, listed openly so the owner decides whether to verify or to accept the gap on the record.
+5. List the rejected states explicitly so false closure is blocked up front: e.g. exit code ignored, a test that passes without exercising the user-facing requirement, a claim broader than its evidence, scope that drifted past the stated non-goals.
+6. Hand the card back as the contract the work will be judged against, and name what still needs an owner decision (which gaps are acceptable, which must be closed before acceptance).
+
+## Copy-paste prompt
+
+```text
+You are helping me with acceptance definition in a local-first AI collaboration workspace.
+
+Task: Define observable pass criteria and required evidence before work starts.
+
+Trigger:
+Use before any work where 'looks good' would be too vague and where a wrong 'done' would propagate: an implementation, a piece of writing, a research result, a cleanup, or any artifact another session or person will trust. Define done BEFORE the work starts, not after.
+
+Do not use when:
+Skip the full ceremony for a throwaway one-line change, a quick fact lookup, or a step you will fully re-check by hand in the next minute anyway. Writing a six-part acceptance card for a trivial edit is cost you pay for nothing, and ceremony with no payoff trains people to skip acceptance when it actually matters.
+
+Input:
+The task goal and the exact artifact expected. The quality bar and constraints. The verification commands or manual checks actually available (the real test command, the real grep, the real way to reproduce). The rejected states that must never be silently accepted. If the work is already partly done, the completion claims made so far so each can be tagged with a state.
+
+Process:
+1. Turn the goal into inspectable deliverables: name the file, the behavior, the output a skeptical reviewer could open and check. A deliverable you cannot point at is a deliverable you cannot accept.
+2. Write each pass criterion so it is mechanically checkable (a command that exits 0, a string that must appear, a behavior a stranger can reproduce), not a vibe like 'works well' or 'is clean'.
+3. Bind every completion claim to one of exactly three states and forbid any fourth: NOT DONE (nothing to show yet), DONE-PENDING-VERIFICATION (built but not yet proven), ACCEPTED (proven and signed off). Ban soft words like 'basically done', 'should be fine', 'mostly working' — they hide which state the work is really in.
+4. Require that any DONE-PENDING-VERIFICATION claim carry three-part evidence, and that the three parts are present before the claim counts: (1) WHAT CHANGED — file plus line plus a one-line description, specific enough that a reader sees the change in thirty seconds; (2) REAL COMMAND OUTPUT — the actual pasted text of grep -n / diff / wc -l / ls -la / the test run, not a verbal 'it is landed' or 'tests pass'; (3) WHAT IS NOT YET VERIFIED — the blind spots, edge cases, cross-file effects, and downstream dependencies, listed openly so the owner decides whether to verify or to accept the gap on the record.
+5. List the rejected states explicitly so false closure is blocked up front: e.g. exit code ignored, a test that passes without exercising the user-facing requirement, a claim broader than its evidence, scope that drifted past the stated non-goals.
+6. Hand the card back as the contract the work will be judged against, and name what still needs an owner decision (which gaps are acceptable, which must be closed before acceptance).
+
+Output shape:
+- Deliverables: the concrete artifacts, each one something a reviewer can open and inspect.
+- Pass criteria: numbered, each mechanically checkable.
+- Required checks: the exact command or manual step that proves each criterion.
+- Three states in use: which claims are NOT DONE / DONE-PENDING-VERIFICATION / ACCEPTED right now.
+- Required evidence per claim: the three-part block (what changed / real command output / what is not yet verified) demanded before any DONE-PENDING-VERIFICATION claim is trusted.
+- Rejected states: the failure conditions that must never be silently accepted.
+- Owner decision needed: which residual gaps need a human call before acceptance.
+
+Pass bar (do not pass unless all hold):
+- Every pass criterion is checkable by a named command or a reproducible manual step, not by opinion.
+- Each completion claim is tagged NOT DONE / DONE-PENDING-VERIFICATION / ACCEPTED, with no soft fourth state.
+- Every DONE-PENDING-VERIFICATION claim has all three evidence parts, and part two is real pasted command output, not a verbal assurance.
+- Rejected states are written down so false closure has an explicit tripwire.
+- What stays unverified is named openly and left to the owner to accept or close, not buried.
+
+Reject bar (send back if any holds):
+- A criterion is a vibe ('looks clean', 'works well') that no command or reproducible step can test.
+- A claim says 'done' / 'basically done' / 'should be fine' without a state tag, so the reviewer cannot tell proven from unproven.
+- A DONE-PENDING-VERIFICATION claim rests on a verbal 'it landed' or 'tests pass' with no pasted output — exactly the gap where a fluent claim outruns the evidence.
+- A test passes but does not exercise the actual user-facing requirement, and that is being counted as acceptance.
+- Unverified areas are folded into 'done' instead of being listed for an owner decision.
+
+Rules:
+- Work only from the material I provide.
+- Keep private material local; use public-safe synthetic wording for examples.
+- Label facts, assumptions, and unverified claims.
+- Do not claim to understand my private business beyond the provided context.
+
+Material:
+[paste redacted material here]
+```
+
+## Expected output
+
+- Deliverables
+- Pass criteria
+- Required checks
+- Rejected states
+- Evidence needed
+- Owner decision needed
+
+## Counter-example
+
+Synthetic: an assistant reports 'Done — added keyboard reordering to the task board and all tests pass.' Under this prompt the claim is tagged DONE-PENDING-VERIFICATION and the three-part evidence is demanded. Part two comes back empty: there is no pasted test output for a keyboard case, only the sentence 'tests pass'. Acceptance is withheld. When the real `grep -n moveTask` and test run are pasted, they show the keyboard handler only logs the key and never calls the reorder function and no keyboard test exists — so the verbal 'all tests pass' was a half-product claim the evidence never backed.
+
+## Failure modes
+
+- Accepting intent instead of observable output.
+- Writing criteria after the work is already done.
+- Letting tests pass even though they do not prove the user-facing requirement.
+- Accepting a verbal 'it is done / it landed' with no pasted command output behind it.
+- Collapsing 'not verified yet' into 'done' so the reviewer cannot tell which claims are actually proven.
+
+## Example
+
+For a CLI dry-run task, acceptance requires exit 0, no files created, clear stdout, and a test proving the target directory stays empty.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/prompts/guard-review.md

@@ -0,0 +1,116 @@
+# Guard review
+
+Purpose: Review an artifact against context, acceptance, evidence, and privacy boundaries.
+
+## Scenario
+
+Use after a draft or implementation exists and before future work treats it as trusted.
+
+## Input requirements
+
+- Artifact under review.
+- Context package.
+- Acceptance card.
+- Verification evidence and known unverified areas.
+
+## Operating steps
+
+1. Lead with findings, not compliments. The job is to find what is wrong before it propagates, not to reassure.
+2. Hunt for the five faces of a half-product — work that looks finished but is not — and for each, run its concrete tell. (1) DONE BUT NOT ACTUALLY DONE: the report says complete; demand the command plus real output and confirm it was actually run, not narrated. (2) PAPER EXISTS BUT THE FUNCTION DOES NOT: the file/hook/feature is present but never wired in; check that it is actually invoked and produces a real effect, not just that it exists on disk. (3) NUMBERS LOOK RIGHT BUT THE DENOMINATOR IS WRONG: a clean percentage or count; pin the exact scope and denominator and recompute, because pending and not-started items get quietly mixed in. (4) JUDGMENT THEATER: 'I judged it safe / I reviewed it'; require a named failure scenario actually tried, or an independent check — a verdict with no attempted break is decoration. (5) CITATION DRIFT: a real source is cited but misquoted, dropped a clause, or summarized into a different claim; open the source and compare the quoted span word-for-word, because drift looks more trustworthy than invention.
+3. Treat the author's own self-assessment as unreliable in seven specific zones and re-verify each independently rather than accepting 'I checked it': (1) counts — fields, lines, items, totals drift between two spots in the same artifact; (2) self-audit checklists with empty filler rows like 'expected N' or a bracketed blank but no actual result filled in; (3) self-audit table rows that describe a check in prose but never show the command that performs it; (4) 'tested' claims that state an expected value but no observed value; (5) attention on long documents — past a few hundred lines a self-check goes formal and misses things, so spot-check the tail, not just the top; (6) self-rule-compliance — 'I followed rule X strictly' is contradicted by at least one counter-instance often enough that it cannot be taken on faith; (7) running totals carried across sessions, which accumulate off-by-one drift. In all seven, the sentence 'I already verified this' is itself the thing not to trust.
+4. Tie every issue to a requirement, a line, a section, or a specific missing piece of evidence. A finding that cannot point at a spot is a vibe, not a finding.
+5. Sort findings into blocker / high / medium / residual, and state which are decision-changing.
+6. State the GUARD LEVEL — how strong the evidence you actually had was — because it caps the verdict you may give. L0: you saw only a completion summary. L1: the artifact and acceptance card exist but there is no real run/test output. L2: you have the author's commands or tests but you are a single tool / single model family. L3: there is a structured evidence pack AND a guard from a different model family pressed on it. L4: on top of that cross-family review (L3), you ALSO independently re-ran the key evidence and reconciled it to a recorded run — a rerun alone, single-family, stays L2.
+7. Return ONE of the four standard verdicts, bounded by the level — pass / reject / insufficient_evidence / pass_with_risk. The ceiling: L0 can only be insufficient_evidence; L1 cannot pass (best is reject or pass_with_risk); L2 (single tool) tops out at pass_with_risk; a plain pass needs L3+ (the cross-family pack); an L4 pass must cite BOTH the cross-family pack AND your reconciled rerun output. A pass_with_risk is NOT 'accepted' on your say-so — the owner must explicitly accept the named residual risk. For anything not fixed, name it as residual risk on the record. A reviewer never silently upgrades 'reads fine' into 'verified'.
+
+## Copy-paste prompt
+
+```text
+You are helping me with guard review in a local-first AI collaboration workspace.
+
+Task: Review an artifact against context, acceptance, evidence, and privacy boundaries.
+
+Trigger:
+Use after a draft or implementation exists and before any future work treats it as trusted: a completion claim, a release candidate, a citation-heavy document, a 'done and tested' report, or any artifact whose wrong 'looks fine' would propagate into later work.
+
+Do not use when:
+Skip the full review on low-stakes, easily reversible work, or a step the owner is about to fully re-run by hand: a one-line wording fix, a scratch draft, a trivial config tweak. A heavy guard pass on throwaway work is ceremony, and ceremony with no payoff trains people to skip review when it matters.
+
+Input:
+The artifact under review, with stable line or section references so a finding can cite an exact spot. The acceptance card or definition of done it claims to meet. The context boundary (goal, scope, non-goals). The verification evidence the completion claim rests on (real command output, test results, a reproduced behavior) or a clear note that none exists. Which model family drafted it, so a same-family 'I reviewed my own work' is weighted as the weak signal it is.
+
+Process:
+1. Lead with findings, not compliments. The job is to find what is wrong before it propagates, not to reassure.
+2. Hunt for the five faces of a half-product — work that looks finished but is not — and for each, run its concrete tell. (1) DONE BUT NOT ACTUALLY DONE: the report says complete; demand the command plus real output and confirm it was actually run, not narrated. (2) PAPER EXISTS BUT THE FUNCTION DOES NOT: the file/hook/feature is present but never wired in; check that it is actually invoked and produces a real effect, not just that it exists on disk. (3) NUMBERS LOOK RIGHT BUT THE DENOMINATOR IS WRONG: a clean percentage or count; pin the exact scope and denominator and recompute, because pending and not-started items get quietly mixed in. (4) JUDGMENT THEATER: 'I judged it safe / I reviewed it'; require a named failure scenario actually tried, or an independent check — a verdict with no attempted break is decoration. (5) CITATION DRIFT: a real source is cited but misquoted, dropped a clause, or summarized into a different claim; open the source and compare the quoted span word-for-word, because drift looks more trustworthy than invention.
+3. Treat the author's own self-assessment as unreliable in seven specific zones and re-verify each independently rather than accepting 'I checked it': (1) counts — fields, lines, items, totals drift between two spots in the same artifact; (2) self-audit checklists with empty filler rows like 'expected N' or a bracketed blank but no actual result filled in; (3) self-audit table rows that describe a check in prose but never show the command that performs it; (4) 'tested' claims that state an expected value but no observed value; (5) attention on long documents — past a few hundred lines a self-check goes formal and misses things, so spot-check the tail, not just the top; (6) self-rule-compliance — 'I followed rule X strictly' is contradicted by at least one counter-instance often enough that it cannot be taken on faith; (7) running totals carried across sessions, which accumulate off-by-one drift. In all seven, the sentence 'I already verified this' is itself the thing not to trust.
+4. Tie every issue to a requirement, a line, a section, or a specific missing piece of evidence. A finding that cannot point at a spot is a vibe, not a finding.
+5. Sort findings into blocker / high / medium / residual, and state which are decision-changing.
+6. State the GUARD LEVEL — how strong the evidence you actually had was — because it caps the verdict you may give. L0: you saw only a completion summary. L1: the artifact and acceptance card exist but there is no real run/test output. L2: you have the author's commands or tests but you are a single tool / single model family. L3: there is a structured evidence pack AND a guard from a different model family pressed on it. L4: on top of that cross-family review (L3), you ALSO independently re-ran the key evidence and reconciled it to a recorded run — a rerun alone, single-family, stays L2.
+7. Return ONE of the four standard verdicts, bounded by the level — pass / reject / insufficient_evidence / pass_with_risk. The ceiling: L0 can only be insufficient_evidence; L1 cannot pass (best is reject or pass_with_risk); L2 (single tool) tops out at pass_with_risk; a plain pass needs L3+ (the cross-family pack); an L4 pass must cite BOTH the cross-family pack AND your reconciled rerun output. A pass_with_risk is NOT 'accepted' on your say-so — the owner must explicitly accept the named residual risk. For anything not fixed, name it as residual risk on the record. A reviewer never silently upgrades 'reads fine' into 'verified'.
+
+Output shape:
+- Verdict: one of pass / reject / insufficient_evidence / pass_with_risk (with the single decisive reason).
+- Guard level: L0 / L1 / L2 / L3 / L4 — the strength of the evidence you actually had, which bounds the verdict above.
+- Findings ordered by severity, each tied to a line, section, requirement, or missing evidence.
+- Half-product check: which of the five faces appeared, and the tell that exposed it.
+- Self-assessment check: which of the seven unreliable zones were re-verified independently and what that re-check found.
+- Evidence: the command output, citation comparison, or reproduction the verdict rests on (for an L4 pass, the cross-family pack AND your reconciled rerun output).
+- Required fixes: the concrete change each blocker needs.
+- Residual risk: what stays unverified and who must accept it (a pass_with_risk needs an explicit owner sign-off).
+
+Pass bar (do not pass unless all hold):
+- The verdict is within the guard level's ceiling: no plain pass below L3, no pass from a single tool, no L4 pass without BOTH a cross-family pack and a reconciled rerun, and L0 only ever yields insufficient_evidence.
+- Every completion claim is backed by evidence the guard could actually point to, not by the author's assurance.
+- None of the five half-product faces survives unexamined; any that appeared was caught with its concrete tell.
+- Each of the seven self-assessment zones that applies was re-verified by the guard, not taken on the author's 'I checked it'.
+- All acceptance criteria are met, or the unmet ones are named as accepted residual risk rather than hidden; any pass_with_risk has an explicit owner sign-off.
+- No private material leaked and scope stayed inside the stated boundary.
+
+Reject bar (send back if any holds):
+- The verdict claims more than the guard level allows — a plain pass on summary-only or single-tool evidence, or an L4 pass with no cross-family pack or no reconciled rerun (the 'single tool dressed up as a binding pass' failure).
+- A pass_with_risk is treated as accepted with no explicit owner sign-off on the residual risk.
+- A completion claim asserts more than the evidence shows — the classic 'said it was done but it was not'.
+- A file/feature is counted as working purely because it exists, with no proof it is wired in and produces an effect.
+- A number or percentage is accepted without pinning its denominator, so not-started items are silently inflating it.
+- A safety or correctness call is 'I judged it fine' with no failure scenario tried and no independent check.
+- A citation is trusted without opening the source, and a word-for-word compare would have shown drift.
+- The review leans on the author's self-audit in one of the seven unreliable zones instead of re-verifying it.
+
+Rules:
+- Work only from the material I provide.
+- Keep private material local; use public-safe synthetic wording for examples.
+- Label facts, assumptions, and unverified claims.
+- Do not claim to understand my private business beyond the provided context.
+
+Material:
+[paste redacted material here]
+```
+
+## Expected output
+
+- Verdict
+- Findings ordered by severity
+- Evidence
+- Required fixes
+- Residual risk
+- Pass or reject recommendation
+
+## Counter-example
+
+Synthetic: an artifact ships with a confident summary, a self-audit table every row ticked, and the line 'I verified all 12 acceptance items pass.' A tone-only review would approve. Under this prompt: the self-audit rows describe checks but show no commands (zone 3), 'tested' rows give expected values but no observed ones (zone 4), and the count '12' is 11 when actually listed (zone 1). Re-verifying independently shows two items were never wired in (half-product face 2) and one cited source was summarized into a claim it never made (face 5). Because the guard only had the author's artifact and no real run, this is guard level L1 — which cannot pass anyway. Verdict: reject — the polished surface was hiding three unproven claims, which is exactly why the author's own 'I verified it' could not clear the gate.
+
+## Failure modes
+
+- Rubber-stamping the same assistant's output.
+- Reviewing tone while ignoring the acceptance card.
+- Calling work complete without fresh verification evidence.
+- Trusting the author's own 'I checked it' on counts, citations, or self-rule-compliance — exactly the claims a model is worst at self-judging.
+- Reading a polished structure (headings, summary, confident prose) as proof the underlying thing actually runs.
+
+## Example
+
+Guard rejects a README that claims multi-tool integration when the code only writes adapter guidance files.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/prompts/handoff-generation.md

@@ -0,0 +1,110 @@
+# Handoff generation
+
+Purpose: Write a next-session state card with completed, pending, blocked, and unverified work.
+
+## Scenario
+
+Use before stopping, changing tools, delegating, or compressing a long task into a resumable state.
+
+## Input requirements
+
+- Current goal and status.
+- Completed work and changed artifacts.
+- Verification commands and outputs.
+- Blockers, decisions, and the next action.
+
+## Operating steps
+
+1. State the goal in one sentence, then separate the work into done / pending / blocked / unverified. Do not narrate a story; transfer a state a stranger can act on.
+2. Record the exact commands or checks already run with their real outputs — including failures shown openly, never smoothed into a summary. A check claimed but not shown is treated as not run.
+3. Frame the option list honestly as a menu, not the whole map: it is the author's view of what comes next, and the author may have missed, misordered, or mis-scoped an item. Mark which options are well-grounded and which are guesses.
+4. Give the receiver an explicit first-round judgment to run before executing, not just a task to pick: (1) what is this next stint actually for — restate the main-line goal, the current sub-task, and the completion bar; (2) is the handed-off option list exhaustive — what did the author miss; (3) is there an unlisted item D or E, and if so does it serve the main line or hijack it? An option list you accept without questioning is an option list whose blind spots you inherit.
+5. Set the discipline for new items: a genuinely high-signal item that does NOT serve the current main line is recorded as a parked / after-closeout residual, not seized on round one. High signal is not the same as 'do it now'; the main line that was handed off keeps priority unless the owner re-points it.
+6. Give one concrete first action and the exact baseline to start from, so the receiver re-enters work cleanly instead of re-deriving the starting point or re-explaining the background.
+
+## Copy-paste prompt
+
+```text
+You are helping me with handoff generation in a local-first AI collaboration workspace.
+
+Task: Write a next-session state card with completed, pending, blocked, and unverified work.
+
+Trigger:
+Use before work crosses a boundary: a session is ending, a different tool or model is taking over, a long task is being compressed into a resumable state, or you are delegating to someone who was not in the original context.
+
+Do not use when:
+Skip the full packet when the same session simply continues, or for a trivial task with a single obvious next step and no state worth transferring. A formal handoff for a one-line continuation is overhead the receiver does not need.
+
+Input:
+The goal in the author's words and the current status. The completed work and the artifacts that changed. The exact verification commands run and their real outputs (including the ones that failed). The blockers, the decisions already made, the sealed baseline (the exact point being handed off), and the author's best read of the next action. Crucially, an honest note of what the author may have left off the list.
+
+Process:
+1. State the goal in one sentence, then separate the work into done / pending / blocked / unverified. Do not narrate a story; transfer a state a stranger can act on.
+2. Record the exact commands or checks already run with their real outputs — including failures shown openly, never smoothed into a summary. A check claimed but not shown is treated as not run.
+3. Frame the option list honestly as a menu, not the whole map: it is the author's view of what comes next, and the author may have missed, misordered, or mis-scoped an item. Mark which options are well-grounded and which are guesses.
+4. Give the receiver an explicit first-round judgment to run before executing, not just a task to pick: (1) what is this next stint actually for — restate the main-line goal, the current sub-task, and the completion bar; (2) is the handed-off option list exhaustive — what did the author miss; (3) is there an unlisted item D or E, and if so does it serve the main line or hijack it? An option list you accept without questioning is an option list whose blind spots you inherit.
+5. Set the discipline for new items: a genuinely high-signal item that does NOT serve the current main line is recorded as a parked / after-closeout residual, not seized on round one. High signal is not the same as 'do it now'; the main line that was handed off keeps priority unless the owner re-points it.
+6. Give one concrete first action and the exact baseline to start from, so the receiver re-enters work cleanly instead of re-deriving the starting point or re-explaining the background.
+
+Output shape:
+- Goal: one sentence.
+- Current status: done / pending / blocked / unverified, kept separate.
+- Verification evidence: the exact commands run and their real outputs, failures included.
+- Option menu (not the map): the next-step options, each marked well-grounded or guess, with a note of what may be missing.
+- Receiver's first-round check: the three questions to answer before executing (what is this for / is the list exhaustive / is there an unlisted D-or-E that serves vs hijacks the main line).
+- Parked residuals: high-signal items that do not serve the current main line, recorded for later, not seized now.
+- Next action: one concrete first step plus the exact baseline to start from.
+
+Pass bar (do not pass unless all hold):
+- Done / pending / blocked / unverified are cleanly separated, with no failed check hidden inside a summary.
+- Every verification claim shows its real command and output, so 'verified' means shown, not asserted.
+- The option list is framed as the author's menu, not the whole map, with missing or guessed items flagged.
+- The receiver is handed an explicit first-round judgment (what is this for / is the list exhaustive / is there a D or E) rather than just a task to pick.
+- A single concrete next action and the exact starting baseline are stated, and off-main-line items are parked rather than promoted to round one.
+
+Reject bar (send back if any holds):
+- The handoff is a narrative of what happened instead of an actionable state transfer.
+- A check is claimed ('tests pass') with no command or output shown, so the receiver must rediscover it.
+- The option list is presented as the complete and only set of next steps, inviting the receiver to inherit the author's blind spots.
+- A failed or skipped check is smoothed over rather than surfaced in the unverified column.
+- A tempting new item is teed up as the immediate next action even though it does not serve the handed-off main line.
+
+Rules:
+- Work only from the material I provide.
+- Keep private material local; use public-safe synthetic wording for examples.
+- Label facts, assumptions, and unverified claims.
+- Do not claim to understand my private business beyond the provided context.
+
+Material:
+[paste redacted material here]
+```
+
+## Expected output
+
+- Goal
+- Current status
+- Completed
+- Pending
+- Blocked
+- Verification evidence
+- Next action
+
+## Counter-example
+
+Synthetic: a handoff lists options A/B/C for finishing a release and says 'next: do B'. The receiver runs the first-round check instead of grabbing B. Question two exposes that the author never listed reconciling a data-count mismatch — an unlisted item D — and question three judges that D actually blocks the release, so it serves the main line and is promoted; meanwhile a flashy idea E (add a new export format) is high-signal but off the main line, so it is parked as an after-closeout residual rather than hijacking round one. Treating the menu as the whole map would have shipped the release with the count bug the author had silently omitted.
+
+## Failure modes
+
+- Writing a story instead of a state transfer.
+- Hiding failed checks in a summary.
+- Leaving the next assistant to rediscover the first command.
+- Presenting the option list as the whole world, so the receiver never asks what the author missed.
+- Letting the receiver grab a tempting new item on round one and hijack the main line that was actually handed off.
+
+## Example
+
+Handoff says: tests pass, pack smoke not run, adapter installer added, next action is fresh temp install.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.