ai-collab-open-system 0.1.0

package/.aict/mechanisms/task-splitting/EXAMPLE.synthetic.md

@@ -0,0 +1,53 @@
+# Task Splitting Synthetic Example
+
+This is a public-safe synthetic example for the AI Collaboration Open System. It is local-first and contains no private account, customer, route, hook, or conversation material.
+
+## Synthetic example
+
+A synthetic app rebuild fails the self-check on input volume and topic spread, so it splits by deliverable into CLI contract, workspace content, privacy scan, docs, then package smoke — each a self-contained packet — instead of one prompt that overflows midway.
+
+## Full worked example (filled end to end)
+
+An owner wants to hand a worker AI a single big request: 'Rebuild our synthetic note app — fix the command-line entry, regenerate all the workspace content, run a privacy pass, rewrite the docs, and smoke-test the package — here are the dozen-plus files you need.' Before dispatching, they run Task Splitting.
+
+### Main goal (one sentence)
+Rebuild the synthetic note app so a stranger can install it, generate the workspace, and trust that it is privacy-clean and documented.
+
+### Pre-dispatch self-check (example values, tune for your own tools)
+- Q1 too many required inputs to read in one pass? YES. The request points at more than a dozen files; pasting all of them would crowd out room to actually work.
+- Q2 spans multiple unrelated deliverables? YES. Command-line entry, content generation, a privacy pass, docs, and a package smoke test are five different kinds of output with different acceptance.
+- Q3 would consume a large share of the context window? YES. The combined inputs plus the expected outputs would eat most of the budget, leaving little headroom before quality drops.
+- Q4 has this shape of task stalled before? YES. A prior 'do it all in one prompt' attempt ran out of room partway and returned a half-finished result.
+- Q5 reusing one long prompt across model families? Partly. The same packet might be sent to more than one worker, so stale nearby context from an earlier run could bleed in.
+Result: four-plus clear yeses. Split.
+
+### Split decision and seam
+Split by DELIVERABLE, not by line count. Five self-contained packets, one coherent outcome each:
+- Packet 1 — Command-line entry: make `init` create the workspace from a clean target, no unsafe fallback. Acceptance: a fresh install produces the expected files and exits cleanly.
+- Packet 2 — Workspace content: regenerate the generated content so it matches the generator. Acceptance: the committed content is byte-for-byte what the generator emits.
+- Packet 3 — Privacy pass: scan for leaked paths, secrets, and private material. Acceptance: the scan runs clean on the whole tree.
+- Packet 4 — Docs: rewrite the start-here and overview so a newcomer can run the first loop. Acceptance: a reader can follow it end to end without the source chat.
+- Packet 5 — Package smoke: pack the project in a temp directory and confirm the required files ship. Acceptance: the dry-run pack lists every required file.
+
+### Sub-packets are self-contained (no cross-references)
+Each packet restates the one-sentence goal, carries only the inputs it needs, and names its own acceptance. Packet 4 (docs) does NOT say 'document whatever Packet 2 generated' — it restates which surfaces to document, so it can run even if Packet 2 is still in flight in another session.
+
+### Dependency order
+1 (entry) -> 2 (content) are loosely ordered because content is generated by the entry path; 3 (privacy) and 4 (docs) can run in parallel once content exists; 5 (package smoke) runs last as the end-to-end check. None of them embed another packet's private output.
+
+### First independently verifiable packet
+Packet 1 (command-line entry): a fresh install either produces the expected files and exits clean, or it does not — verifiable on its own before anything else is built on top.
+
+### Merge point
+After all five pass their own acceptance, recombine by running the full sequence on one clean target — install, generate, privacy-scan, read the docs, pack — and confirm the original goal holds end to end.
+
+### Deferred slices (do-not-handle-yet)
+Visual restyling of the generated docs is parked: reason — it is polish, not correctness, and would inflate Packet 4; revisit condition — only after all five packets are green and the end-to-end merge passes. Parked on purpose, with a way back, not dropped.
+
+## 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/task-splitting/FAILURE_MODES.md

@@ -0,0 +1,25 @@
+# Task Splitting 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
+
+- Splitting by file extension instead of user-visible outcome.
+- Starting the most interesting slice rather than the first verifiable slice.
+- Deferred work is lost because it has no handoff note.
+
+## Common misuse (operator errors that look fine but break the mechanism)
+
+- Splitting by line count or file type ('first 200 lines to packet A') instead of by outcome, which hands each packet half a feature and guarantees a painful merge.
+- Calling it split but leaving packets that reference each other ('continue from B's result'), which rebuilds the original oversized, serial task.
+- Starting with the most interesting packet instead of the first one that can be verified independently, so progress cannot be confirmed before later packets pile on.
+- Treating the example numbers as hard law and either over-splitting tiny tasks or refusing to split because a count was one under an arbitrary line.
+- Deferring work with no revisit condition, so 'do not handle yet' quietly becomes 'never handled'.
+- Skipping the self-check entirely and only reacting after the worker stalls — the whole point is to catch the oversized packet before dispatch, not after it has already collapsed.
+
+## 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/task-splitting/PROMPT.md

@@ -0,0 +1,72 @@
+# Task Splitting Prompt
+
+This prompt belongs to the AI Collaboration Open System. Use it in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Before you hand a task to another AI, run a five-question pre-dispatch self-check; if any answer is yes, split the task by topic or deliverable (not by line count) into self-contained sub-packets, so a too-large prompt does not stall, overflow the context window, or collapse in quality midway.
+
+## Copy-paste prompt
+
+```text
+Use the Task Splitting mechanism from my local AI Collaboration Open System workspace.
+
+Purpose:
+Before you hand a task to another AI, run a five-question pre-dispatch self-check; if any answer is yes, split the task by topic or deliverable (not by line count) into self-contained sub-packets, so a too-large prompt does not stall, overflow the context window, or collapse in quality midway.
+
+Trigger:
+Run the self-check before dispatching ANY non-trivial task to an external AI (a worker model, another tool, a fresh session). The point is to catch an oversized packet at the door, before the other side accepts it and quietly degrades.
+
+Do not use when:
+Do not split a task that already fits comfortably: a single focused change, one short input to read, one deliverable, well inside the model's context budget. Over-splitting has its own cost — it multiplies handoffs, scatters the work across packets, and makes the merge harder than the original task. If the self-check is all 'no', keep it as one packet.
+
+Input:
+[paste redacted task material, context package, and acceptance card here]
+
+Process:
+1. Run the five-question pre-dispatch self-check. Split if ANY answer is yes: (1) Are there too many required inputs to paste or read in one pass? (2) Does the task span multiple unrelated topics or deliverables? (3) Would it consume a large share of the model's context window? (4) Has this kind of task stalled or overflowed before? (5) Are you reusing one long prompt across different model families, where stale 'nearby' context from a prior run could bleed in? Treat all the numbers below as example values to calibrate for your own tools and model, not fixed law.
+2. If the answer is split, cut by TOPIC or DELIVERABLE, never by line count. A natural seam is 'one self-contained outcome', not 'the first N lines'. Splitting by size alone produces packets that each carry half an idea.
+3. Make every sub-packet self-contained: it states the full goal, its own slice of context, its own acceptance, and everything needed to run alone. A packet that cannot run without three others was not really split.
+4. Forbid cross-references between sub-packets for each other's private content. Packet B must not say 'use what A produced'; if B needs something, restate it inside B. Cross-references re-create the giant task you were trying to avoid and make parallel work impossible.
+5. Order the packets by dependency, pick the first one that can be verified on its own, and define the merge point: how the finished packets recombine into the original goal.
+6. Defer lower-value slices with an explicit do-not-handle-yet note (why parked, when to revisit) so deferred work is parked on purpose, not silently dropped.
+
+Output shape:
+- Self-check result: each of the five questions answered yes/no, with the one-line reason any 'yes' triggers a split.
+- Split decision: split or keep-as-one, and the seam used (which topics / deliverables).
+- Sub-packet list: for each packet — its goal, its own inputs, its own acceptance, and a note that it is self-contained.
+- Dependency order and the first independently verifiable packet.
+- Merge point: how the packets recombine into the original goal.
+- Deferred slices: anything parked, with a do-not-handle-yet reason and revisit condition.
+
+Return:
+- Decision-changing findings only
+- Evidence used
+- Required fixes
+- Residual risk
+- Next action
+
+Pass bar (do not pass unless all hold):
+- The five-question self-check was actually run and recorded before dispatch.
+- Each sub-packet can run on its own: full goal, own context, own acceptance, no dependency on another packet's private content.
+- The split follows topic / deliverable seams, so each packet is one coherent outcome rather than an arbitrary slice of size.
+- There is a clear dependency order, a first verifiable packet, and a stated merge point.
+- Deferred work has an explicit do-not-handle-yet note, so nothing was silently dropped.
+
+Reject bar (send back if any holds):
+- The task was dispatched whole even though a self-check answer was yes (the oversized packet that stalls or degrades midway).
+- It was split by line count or file count instead of by topic / deliverable, so packets each carry partial ideas.
+- A sub-packet says 'use what the other packet produced', re-creating the monolith and blocking parallel work.
+- A packet cannot run alone because its goal, context, or acceptance lives in a different packet.
+- Lower-value work was dropped with no do-not-handle-yet note, so it silently disappears.
+
+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/task-splitting/README.md

@@ -0,0 +1,79 @@
+# Task Splitting
+
+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
+
+Before you hand a task to another AI, run a five-question pre-dispatch self-check; if any answer is yes, split the task by topic or deliverable (not by line count) into self-contained sub-packets, so a too-large prompt does not stall, overflow the context window, or collapse in quality midway.
+
+## When to use
+
+Run the self-check before dispatching ANY non-trivial task to an external AI (a worker model, another tool, a fresh session). The point is to catch an oversized packet at the door, before the other side accepts it and quietly degrades.
+
+## When not to use
+
+Do not split a task that already fits comfortably: a single focused change, one short input to read, one deliverable, well inside the model's context budget. Over-splitting has its own cost — it multiplies handoffs, scatters the work across packets, and makes the merge harder than the original task. If the self-check is all 'no', keep it as one packet.
+
+## Input shape
+
+The full goal in one sentence. The candidate sub-tasks or deliverables the goal implies. The complete list of inputs the work needs to read. The dependencies between sub-tasks (what must finish before what). The risk level, and any history of this kind of task stalling before. A rough sense of how much of the model's context window the packet would consume.
+
+## Input materials
+
+- Full goal in one sentence, so every sub-packet can trace back to it.
+- Candidate deliverables: the distinct outputs the goal implies (an implementation, a written piece, a research summary, a review, a migration step).
+- Full input list: every file, document, or reference the work must read, so you can see whether it fits in one pass.
+- Dependency map: which sub-tasks block which, so the split order is runnable and a later packet is not waiting on an earlier one mid-stream.
+- Risk and history: how costly a mid-task collapse would be, and whether this shape of task has stalled before.
+- Context-budget estimate: roughly how much of the target model's window the packet would use, expressed as a fraction so it travels across different tools.
+
+## Process
+
+1. Run the five-question pre-dispatch self-check. Split if ANY answer is yes: (1) Are there too many required inputs to paste or read in one pass? (2) Does the task span multiple unrelated topics or deliverables? (3) Would it consume a large share of the model's context window? (4) Has this kind of task stalled or overflowed before? (5) Are you reusing one long prompt across different model families, where stale 'nearby' context from a prior run could bleed in? Treat all the numbers below as example values to calibrate for your own tools and model, not fixed law.
+2. If the answer is split, cut by TOPIC or DELIVERABLE, never by line count. A natural seam is 'one self-contained outcome', not 'the first N lines'. Splitting by size alone produces packets that each carry half an idea.
+3. Make every sub-packet self-contained: it states the full goal, its own slice of context, its own acceptance, and everything needed to run alone. A packet that cannot run without three others was not really split.
+4. Forbid cross-references between sub-packets for each other's private content. Packet B must not say 'use what A produced'; if B needs something, restate it inside B. Cross-references re-create the giant task you were trying to avoid and make parallel work impossible.
+5. Order the packets by dependency, pick the first one that can be verified on its own, and define the merge point: how the finished packets recombine into the original goal.
+6. Defer lower-value slices with an explicit do-not-handle-yet note (why parked, when to revisit) so deferred work is parked on purpose, not silently dropped.
+
+## Output shape
+
+- Self-check result: each of the five questions answered yes/no, with the one-line reason any 'yes' triggers a split.
+- Split decision: split or keep-as-one, and the seam used (which topics / deliverables).
+- Sub-packet list: for each packet — its goal, its own inputs, its own acceptance, and a note that it is self-contained.
+- Dependency order and the first independently verifiable packet.
+- Merge point: how the packets recombine into the original goal.
+- Deferred slices: anything parked, with a do-not-handle-yet reason and revisit condition.
+
+## Pass bar (what counts as done / safe to trust)
+
+- The five-question self-check was actually run and recorded before dispatch.
+- Each sub-packet can run on its own: full goal, own context, own acceptance, no dependency on another packet's private content.
+- The split follows topic / deliverable seams, so each packet is one coherent outcome rather than an arbitrary slice of size.
+- There is a clear dependency order, a first verifiable packet, and a stated merge point.
+- Deferred work has an explicit do-not-handle-yet note, so nothing was silently dropped.
+
+## Reject bar (what sends it back)
+
+- The task was dispatched whole even though a self-check answer was yes (the oversized packet that stalls or degrades midway).
+- It was split by line count or file count instead of by topic / deliverable, so packets each carry partial ideas.
+- A sub-packet says 'use what the other packet produced', re-creating the monolith and blocking parallel work.
+- A packet cannot run alone because its goal, context, or acceptance lives in a different packet.
+- Lower-value work was dropped with no do-not-handle-yet note, so it silently disappears.
+
+## Common misuse
+
+- Splitting by line count or file type ('first 200 lines to packet A') instead of by outcome, which hands each packet half a feature and guarantees a painful merge.
+- Calling it split but leaving packets that reference each other ('continue from B's result'), which rebuilds the original oversized, serial task.
+- Starting with the most interesting packet instead of the first one that can be verified independently, so progress cannot be confirmed before later packets pile on.
+- Treating the example numbers as hard law and either over-splitting tiny tasks or refusing to split because a count was one under an arbitrary line.
+- Deferring work with no revisit condition, so 'do not handle yet' quietly becomes 'never handled'.
+- Skipping the self-check entirely and only reacting after the worker stalls — the whole point is to catch the oversized packet before dispatch, not after it has already collapsed.
+
+## 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/task-splitting/TEMPLATE.md

@@ -0,0 +1,76 @@
+# Task Splitting Template
+
+AI Collaboration Open System mechanism card. Fill this in a local-first workflow with public-safe or redacted material.
+
+## Purpose
+
+Before you hand a task to another AI, run a five-question pre-dispatch self-check; if any answer is yes, split the task by topic or deliverable (not by line count) into self-contained sub-packets, so a too-large prompt does not stall, overflow the context window, or collapse in quality midway.
+
+## Template
+
+### Main goal (one sentence):
+
+
+### Pre-dispatch self-check (answer each; any yes = split; numbers are example values, tune for your tools):
+
+
+###   Q1 too many required inputs to read in one pass?
+
+
+###   Q2 spans multiple unrelated topics / deliverables?
+
+
+###   Q3 would consume a large share of the context window?
+
+
+###   Q4 has this shape of task stalled / overflowed before?
+
+
+###   Q5 reusing one long prompt across model families (nearby-context bleed risk)?
+
+
+### Split decision and seam (by topic / deliverable, never by line count):
+
+
+### Sub-packets (each self-contained: goal + own inputs + own acceptance; no cross-references):
+
+
+### Dependency order:
+
+
+### First independently verifiable packet:
+
+
+### Merge point:
+
+
+### Deferred slices (with do-not-handle-yet reason + revisit condition):
+
+
+
+## Pass bar (tick before you trust the result)
+
+- The five-question self-check was actually run and recorded before dispatch.
+- Each sub-packet can run on its own: full goal, own context, own acceptance, no dependency on another packet's private content.
+- The split follows topic / deliverable seams, so each packet is one coherent outcome rather than an arbitrary slice of size.
+- There is a clear dependency order, a first verifiable packet, and a stated merge point.
+- Deferred work has an explicit do-not-handle-yet note, so nothing was silently dropped.
+
+## Reject bar (send it back if any of these is true)
+
+- The task was dispatched whole even though a self-check answer was yes (the oversized packet that stalls or degrades midway).
+- It was split by line count or file count instead of by topic / deliverable, so packets each carry partial ideas.
+- A sub-packet says 'use what the other packet produced', re-creating the monolith and blocking parallel work.
+- A packet cannot run alone because its goal, context, or acceptance lives in a different packet.
+- Lower-value work was dropped with no do-not-handle-yet note, so it silently disappears.
+
+## 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/modes/README.md

@@ -0,0 +1,11 @@
+# Modes
+
+Modes state what kind of work is happening now. A mode is a boundary, not a personality.
+
+Use one mode at a time: shape, execute, review, handoff, or harvest.
+
+Each mode card below is a full spec, not a one-liner. It states six things so a tool always knows the edges of the current mode: the entry condition that lets you start, the actions allowed, the actions forbidden, the output format, the exit condition that ends the mode, and how it hands off to the other modes. The forbidden line and the handoff line are what keep modes from blurring into one another.
+
+## The loop between modes
+
+Shape comes first when the request is still fuzzy: it turns a rough intent into a signable thin contract before anything is built, so execute starts from a boundary instead of a guess. Then the core loop runs. Execute produces, then review challenges what execute produced; a rejection sends it back to execute, a pass moves it toward handoff or close. Handoff carries state across a session or tool boundary so the receiver re-enters execute cleanly. Harvest runs at a seam or close to lift reusable learning, then returns to whatever mode was active. Naming each entry and exit explicitly is what stops "shape" from sliding into design, "review" from quietly editing, or "execute" from drifting past its task.

package/.aict/modes/execute.md

@@ -0,0 +1,31 @@
+# Execute Mode
+
+Build the agreed artifact, and only that.
+
+## Entry condition
+
+There is a clearly defined task with execution authority granted: a goal, a boundary, and acceptance criteria are all in place.
+
+## Allowed actions
+
+- Create or edit the agreed artifact.
+- Change the in-scope files or sections and save state.
+- Self-verify the work and capture the evidence.
+
+## Forbidden actions
+
+- Doing work outside the stated task or boundary.
+- Crossing a core boundary (rules, security-sensitive areas, anything out of scope) without stopping.
+- Declaring the work done without running the checks.
+
+## Output format
+
+The artifact, the list of changed files or sections, the verification evidence, and an explicit note of what is still unverified.
+
+## Exit condition
+
+The task is wrapped up and has passed acceptance, or it is blocked and must be handed off.
+
+## Inter-mode handoff
+
+When the artifact is done, move to review so an independent pass can challenge it before it is trusted; if work must cross a session or tool boundary first, move to handoff and let the receiver re-enter execute.

package/.aict/modes/handoff.md

@@ -0,0 +1,29 @@
+# Handoff Mode
+
+Compress state so the next session or tool can pick up exactly where this one stopped.
+
+## Entry condition
+
+Work is about to cross a boundary: a session is ending, a different tool is taking over, or a long task has reached a natural seam.
+
+## Allowed actions
+
+- Compress the current state into a structured handoff packet.
+- Seal the baseline (the exact point being handed off) so the receiver starts from a known state.
+
+## Forbidden actions
+
+- Dropping context the receiver needs.
+- Omitting the exact first action the next session should take.
+
+## Output format
+
+A handoff packet: what is done, what is pending, what is blocked, what is unverified, the sealed baseline, and the exact next step.
+
+## Exit condition
+
+The receiver confirms they can pick up from the packet alone, without re-reading the whole history.
+
+## Inter-mode handoff
+
+The receiver reads the packet and re-enters execute on the stated first action, continuing the loop from the sealed baseline rather than from zero.

package/.aict/modes/harvest.md

@@ -0,0 +1,30 @@
+# Harvest Mode
+
+Lift reusable learning out of finished work — into staged, public-safe cards.
+
+## Entry condition
+
+Harvest is triggered, or a phase is closing, and there is reusable value worth saving before it is lost.
+
+## Allowed actions
+
+- Sweep the conversation or finished loop for reusable bits.
+- Draft harvest cards (one item per card) for decisions, lessons, methods, and stable preferences.
+- Redact private material into a general, public-safe form.
+
+## Forbidden actions
+
+- Filing anything into the knowledge base without redacting it first.
+- Deciding on the user's behalf whether a card lands; that confirmation belongs to the user.
+
+## Output format
+
+Harvest cards in a public-safe form, presented as candidates awaiting confirmation.
+
+## Exit condition
+
+The user has confirmed which cards land in the knowledge base.
+
+## Inter-mode handoff
+
+Harvest runs at a seam without taking over the work; once cards are confirmed and filed, it returns control to whatever mode was active before it (typically execute or a close).

package/.aict/modes/review.md

@@ -0,0 +1,28 @@
+# Review Mode
+
+Inspect and challenge the artifact — without changing it.
+
+## Entry condition
+
+There is a produced artifact that needs to be checked before anyone trusts it.
+
+## Allowed actions
+
+- Inspect the artifact against context, acceptance, and evidence.
+- Challenge claims, surface blind spots, and point each finding to a specific line, section, or missing piece of evidence.
+
+## Forbidden actions
+
+- Editing or fixing the artifact under review. Review and repair stay separate, so the reviewer never becomes the author of what it judges.
+
+## Output format
+
+One of the four standard verdicts (pass / reject / insufficient_evidence / pass_with_risk) plus the guard level (L0-L4) for the evidence seen, the findings with severity, the required fixes, and the named residual risk. A plain pass requires L3+ (a cross-family evidence pack); a pass_with_risk is not accepted until the owner explicitly signs off on the residual risk.
+
+## Exit condition
+
+A verdict has been issued.
+
+## Inter-mode handoff
+
+On reject, hand the required fixes back to execute for repair; on pass, move to handoff or to close. Review never applies the fix itself — it returns the artifact to execute for that.

package/.aict/modes/shape.md

@@ -0,0 +1,34 @@
+# Shape Mode
+
+Turn a fuzzy idea into a signable thin contract — before any solution is designed or built.
+
+## Entry condition
+
+The person has a rough intent but nothing crisp enough to act on yet: "I want to improve X", "this feels off", "I have an idea". It sits between exploring the current state and designing a solution; you enter it instead of jumping straight to a plan from a vague request.
+
+## Allowed actions
+
+- Pull the intent into a few anchors (the situation, the wanted result, the result that would be unacceptable, what this round must protect) and name the two or three ambiguities that actually matter.
+- Offer choices instead of asking for a blank-page description: pose comparison questions ("more like A or like B?"), and proactively recommend one to three reference points (an existing product or feature) so the person reacts to something concrete instead of recalling from nothing.
+- Lead with weaknesses before any direction: name the two or three ways the current instinct most easily goes wrong, including what an automated step would amplify and what would be hardest to undo.
+- Rewrite the problem statement when the framing itself is the trap, instead of politely optimizing along the original wording.
+- Give two or three candidate directions in experience terms (what the person will feel, and the cost), each with its single biggest failure point, and let them pick one.
+- Run a preview gate: before the person signs off, show a perceivable preview matched to the work — a mock or wireframe for UI, a 1-2-3 journey walk for a flow, or sample request/response and failure-case examples for backend — so "yes, that's the feeling" is grounded in something they can see, not an abstract description.
+
+## Forbidden actions
+
+- Discussing implementation, writing code, or proposing a technical solution before the contract is confirmed and the preview gate is passed.
+- Asking the person to describe implementation detail (they are not here for that), or handing back "please describe your requirements in detail" instead of offering choices.
+- Giving only one direction with no choice, pushing the job of "say what you want" back onto the person, or skipping the preview gate straight into design or build.
+
+## Output format
+
+A thin contract the person can sign: the success definition in their words, the failure definition and non-goals, the most likely wrong assumption, a short negative list (the two or three things most likely to be misread, missed, or amplified), and the confirmed reference points — followed by a matched preview the person has reacted to.
+
+## Exit condition
+
+The person confirms the thin contract AND the preview gate passes ("yes, that is the feeling"). Before exit, three adversarial questions must be answered: if this is pushed forward as currently understood, what is most likely done wrong; which weakness, left unfixed now, gets amplified by later automation; and is the real fix to the problem statement rather than the answer. Unanswered, the mode does not exit.
+
+## Inter-mode handoff
+
+On a confirmed contract and a passed preview, move to design for a technical plan (or straight to execute for a simple task), carrying the contract as the boundary the build is judged against. If the person rejects the direction, return to the choice step and re-pose it rather than optimizing the dead direction. A discovered framing error is a problem-statement rewrite, not a silent patch.

package/.aict/privacy/COMMERCIAL_BOUNDARY.md

@@ -0,0 +1,34 @@
+# Commercial Boundary
+
+The open-source edition gives the complete generic self-build path.
+
+## Free and open
+
+- Workspace skeleton
+- Six collaboration layers
+- Generic prompts
+- Skills
+- Thin adapters
+- Synthetic cases
+- Privacy and setup docs
+- Health checks and their limitations
+
+## Paid help may include
+
+- Real workflow review
+- Personalized profile calibration
+- Project-specific setup
+- Migration from existing AI workflows
+- Custom guard rules
+- Scenario packs
+- Human review
+- Async audit
+- Long-term workflow improvement
+
+## Required framing
+
+The method is public. Paid help gives users a calibrated version for their real workflow and saves time.
+
+## Forbidden framing
+
+Do not imply that the open version only names problems while paid help unlocks the fix.

package/.aict/privacy/PRIVACY.md

@@ -0,0 +1,36 @@
+# Privacy Boundary
+
+This workspace is local-first. It does not call external AI APIs by default, upload user content, scan the whole disk, or install hooks without consent.
+
+## Public-safe material
+
+- Generic architecture
+- Generic prompts
+- Generic templates
+- Thin tool adapters
+- Synthetic examples
+- Setup docs
+- Known limitations
+
+## Forbidden public material
+
+- Real private governance contents
+- Knowledge-base source material copied from a private system
+- Real personal profile
+- Actual client material
+- Raw private conversations
+- Non-public automation or routing details
+- Internal calibration metrics, scoring configuration, or account-specific habits
+- Local machine paths
+- Tokens, keys, cookies, and credentials
+- Unredacted screenshots
+
+## Redaction standard
+
+Before publishing an example, ask:
+
+```text
+Could a stranger infer the owner's private system, identity, clients, files, habits, or operational routes from this?
+```
+
+If yes, rewrite it as a synthetic example.

package/.aict/privacy/REDACTION_CHECKLIST.md

@@ -0,0 +1,12 @@
+# Redaction Checklist
+
+Use this before publishing an example or sharing a workspace.
+
+- [ ] The case is synthetic or public-safe.
+- [ ] No actual client, employer, or account names appear.
+- [ ] No local machine paths appear.
+- [ ] No raw private conversations appear.
+- [ ] No private tool-routing details or hooks appear.
+- [ ] No tokens, keys, cookies, credentials, or session IDs appear.
+- [ ] No private knowledge-base source material appears.
+- [ ] The example can stand alone without revealing the owner's private system.

package/.aict/profile/CANDIDATES.md

@@ -0,0 +1,44 @@
+# Profile Candidates (buffer before the long-term profile)
+
+This file is the holding area for **proposed** profile preferences. The 10-minute loop (`../walkthroughs/10-minute-your-task.md`, Step 4) can suggest a profile candidate when a stable preference shows up more than once. That suggestion is a guess, not a fact - so it lands here as `proposed` instead of editing your real profile, and an unreviewed guess never hardens into a standing rule future sessions obey.
+
+This is local-first and public-safe. Keep only general, redacted preferences here - no private names, paths, customers, or internal numbers. The row below is a synthetic example, not real data.
+
+## State machine
+
+Every candidate moves through exactly these four states:
+
+| State | Meaning | Touches your long-term profile? |
+| --- | --- | --- |
+| `proposed` | The AI suggested it this loop; not yet reviewed, not trusted. | No |
+| `confirmed` | You reviewed it and it is correct as written. | Yes - it may graduate as-is |
+| `edited` | Correct only after you reword it; the edited line is what graduates. | Yes - the edited line graduates |
+| `dropped` | You reviewed it and it does not belong; kept on the record so it is not re-proposed. | No |
+
+Rule: **only `confirmed` and `edited` candidates graduate into your long-term profile, and only after you say so.** `proposed` and `dropped` never edit your profile. This is the same confirm / edit / drop discipline the harvest mechanism uses for harvested cards - nothing lands on the AI's say-so alone.
+
+## How to use this
+
+1. After a loop, a new candidate is appended below with status `proposed`.
+2. When you review it, change its status to `confirmed`, `edited`, or `dropped` (edit the wording in place if `edited`).
+3. Move `confirmed` / `edited` lines into your profile (`EXAMPLE.synthetic.md` here, or your own real profile file), then mark the row `graduated` in the Notes column or delete it.
+4. Leave `dropped` rows here so the same guess is not proposed every loop.
+
+## Candidates
+
+| Candidate (one line) | Status | Source loop | Reviewed on | Notes |
+| --- | --- | --- | --- | --- |
+| (synthetic) Prefer direct risk calls over reassurance | proposed | synthetic-loop-01 | (not reviewed yet) | example row; replace with your own |
+
+## Why this buffer exists
+
+Without it, the loop would "drop a candidate straight into the profile" - and a one-off observation from a single task could quietly become a permanent rule that every future session obeys, with no human in the loop. The buffer keeps your profile honest: it only ever grows from preferences you actually confirmed.
+
+## This file vs the learning ledger (two surfaces, same discipline)
+
+There are two places a proposed preference can live, and they are partners, not rivals:
+
+- **This file (`CANDIDATES.md`)** is the human view - a table you read and edit by hand while deciding what belongs in your profile. It covers profile candidates only.
+- **The learning ledger (`../state/learning-ledger.jsonl`)** is the machine record the CLI writes - `ai-collab learning add --type profile --content "..."` appends a `proposed` row, `learning confirm/edit/drop` flips its state, and `ai-collab status` echoes back the one preference you most recently confirmed so the next task starts ahead. It also records `harvest` lessons, which this file does not.
+
+Both use the exact same `proposed / confirmed / edited / dropped` states and the same graduation rule (only `confirmed`/`edited` graduate, only when you say so). But they are **two separate stores with no auto-sync, shared id, or dedupe between them** - so pick one place per candidate and keep it there. If you record the same preference in both and then change one, they will drift, and nothing reconciles them for you. When they do disagree, the **learning ledger is the source of truth**: it is what `ai-collab status` reads back and what the machine acts on; `CANDIDATES.md` is a human-only view that no command reads. Use whichever fits the moment - hand-edit this table, or run the `learning` commands - just not both for the same candidate, and let `confirmed`/`edited` lines graduate into your real profile.