ai-collab-open-system 0.1.0

package/.aict/prompts/harvest-extraction.md

@@ -0,0 +1,110 @@
+# Harvest extraction
+
+Purpose: Extract reusable knowledge, prompt fragments, and rule candidates after a loop.
+
+## Scenario
+
+Use after a task finishes, fails in an instructive way, or reveals a repeatable collaboration pattern.
+
+## Input requirements
+
+- Final artifact and review result.
+- What changed the outcome.
+- Reusable snippets or rules.
+- What should stay case-specific.
+
+## Operating steps
+
+1. First ask whether anything here is worth keeping at all. If the honest answer is no, say so and stop — restraint is part of the method, not a failure of it. If the person was asked 'anything you want to keep?' and said no, do not push.
+2. Extract one item per card, each card a single kind of thing — a DECISION (a choice future work should not silently reopen), a LESSON (a mistake and the rule that prevents it), a METHOD (a reusable move or prompt fragment), or a PREFERENCE (a stable way of working). Do not blend a decision, a lesson, and a method into one mushy entry; one card, one thing, so each can be trusted, found, and revisited on its own.
+3. Redact as you extract, not as an afterthought: rewrite every real name, client, path, number, and raw quote into a general, public-safe form before the card is even proposed. The card must carry the lesson, never the private original. Privacy is built into the extraction step, not bolted on later.
+4. Resist generalizing a single incident into a permanent rule. A one-off needs either repeated evidence or an explicit human sign-off before it becomes standing doctrine; otherwise mark it as a candidate, not a rule.
+5. For a DECISION or a LESSON, record its current state honestly — still open, recorded-but-unresolved, resolved, or superseded — so a stale card is not mistaken for live truth.
+6. Present every card as a candidate awaiting confirmation, with a proposed storage target and the next moment it would be reused. Nothing lands in the knowledge base until the human confirms it: the harvester stages, the human files.
+
+## Copy-paste prompt
+
+```text
+You are helping me with harvest extraction in a local-first AI collaboration workspace.
+
+Task: Extract reusable knowledge, prompt fragments, and rule candidates after a loop.
+
+Trigger:
+Use at the end of one loop or conversation: a task finished, failed in an instructive way, or revealed a repeatable collaboration pattern. The goal is to lift the reusable bit before it leaks away, while the context is still fresh.
+
+Do not use when:
+Skip it when nothing reusable happened: a routine answer, a trivial fix, a conversation that taught nothing a future task would want. Do not manufacture a 'lesson' to justify running the step — an invented rule is worse than no rule, because future loops will obey it. If the person had nothing they wanted to keep, stop; do not interrogate them for one.
+
+Input:
+The finished loop or conversation. The final artifact and the review result. What actually changed the outcome (the decision, the mistake, the move that worked). Any reusable snippet, prompt fragment, or candidate rule. And what should stay specific to this case and never be generalized.
+
+Process:
+1. First ask whether anything here is worth keeping at all. If the honest answer is no, say so and stop — restraint is part of the method, not a failure of it. If the person was asked 'anything you want to keep?' and said no, do not push.
+2. Extract one item per card, each card a single kind of thing — a DECISION (a choice future work should not silently reopen), a LESSON (a mistake and the rule that prevents it), a METHOD (a reusable move or prompt fragment), or a PREFERENCE (a stable way of working). Do not blend a decision, a lesson, and a method into one mushy entry; one card, one thing, so each can be trusted, found, and revisited on its own.
+3. Redact as you extract, not as an afterthought: rewrite every real name, client, path, number, and raw quote into a general, public-safe form before the card is even proposed. The card must carry the lesson, never the private original. Privacy is built into the extraction step, not bolted on later.
+4. Resist generalizing a single incident into a permanent rule. A one-off needs either repeated evidence or an explicit human sign-off before it becomes standing doctrine; otherwise mark it as a candidate, not a rule.
+5. For a DECISION or a LESSON, record its current state honestly — still open, recorded-but-unresolved, resolved, or superseded — so a stale card is not mistaken for live truth.
+6. Present every card as a candidate awaiting confirmation, with a proposed storage target and the next moment it would be reused. Nothing lands in the knowledge base until the human confirms it: the harvester stages, the human files.
+
+Output shape:
+- Source: which loop or conversation this came from (public-safe).
+- Cards: one item per card, each typed DECISION / LESSON / METHOD / PREFERENCE — never blended.
+- Redacted form: each card already rewritten public-safe, with no private name, path, number, or raw quote.
+- State (for decisions and lessons): open / recorded-unresolved / resolved / superseded.
+- Candidate vs rule: whether each item is a confirmed rule or a candidate still needing evidence or sign-off.
+- Do not generalize: what must stay case-specific.
+- Storage target and next reuse: where each card would live and when it would next be used — all pending human confirmation.
+
+Pass bar (do not pass unless all hold):
+- Each card carries exactly one kind of thing (decision / lesson / method / preference), not a blend.
+- Every card is already redacted public-safe at the moment it is proposed, carrying the lesson and not the private original.
+- No single incident has been promoted to a permanent rule without repeated evidence or explicit sign-off.
+- Decision and lesson cards show an honest current state, so nothing stale reads as live truth.
+- All cards are staged as candidates for human confirmation; none has been filed into the knowledge base unilaterally.
+
+Reject bar (send back if any holds):
+- Everything got harvested, producing clutter instead of the few items that actually matter.
+- A card blends a decision, a lesson, and a method together, so none of them can be trusted or revisited cleanly.
+- A private name, path, number, or raw quote survives in a card instead of a synthetic rewrite.
+- A one-off anecdote was turned into a standing rule with no repeated evidence and no sign-off.
+- A card was filed straight into the knowledge base without the human confirming it, or the user was interrogated for a lesson after saying there was nothing to keep.
+
+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
+
+- Source task
+- Reusable knowledge
+- Reusable prompts
+- Decision record
+- Rule candidates
+- Do not generalize
+- Storage target
+
+## Counter-example
+
+Synthetic: a release check fails because a packaged build was never smoke-tested. The wrong harvest writes one fat entry mixing the decision, the lesson, and the user's real repo path, then files it automatically. The disciplined harvest stages two separate public-safe candidate cards — a LESSON ('smoke-test the packed package in a throwaway temp directory before claiming a release is ready', state: resolved) and a METHOD (the exact temp-install command, with the private path rewritten to a generic stand-in) — keeps the private repo path out entirely, and waits for the human to confirm before anything lands. And if that same session had ended with nothing instructive, the right move would have been to say 'nothing worth keeping this round' rather than inventing a rule.
+
+## Failure modes
+
+- Harvesting everything and creating clutter.
+- Turning one anecdote into a permanent rule.
+- Saving private raw material instead of a synthetic lesson.
+- Filing a card straight into the knowledge base without waiting for the human to confirm it.
+- Interrogating the user for lessons when nothing this round was actually worth keeping.
+
+## Example
+
+From a failed release check, harvest the rule 'smoke test the packed package in a temp directory' but do not store the user's private repo path.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/prompts/mode-switching.md

@@ -0,0 +1,66 @@
+# Mode switching
+
+Purpose: Switch an assistant between execution, review, planning, and reflection without losing boundaries.
+
+## Scenario
+
+Use when a conversation changes from brainstorming to implementation, from execution to review, or from review to handoff.
+
+## Input requirements
+
+- Current mode and requested new mode.
+- Authority boundary: who may write, review, or decide.
+- Current goal, acceptance card, and stop conditions.
+
+## Operating steps
+
+1. Confirm the old mode and new mode in plain language.
+2. Carry forward only the context needed for the new mode.
+3. Restate what actions are allowed and forbidden.
+4. Name the first output expected in the new mode.
+
+## Copy-paste prompt
+
+```text
+You are helping me with mode switching in a local-first AI collaboration workspace.
+
+Task: Switch an assistant between execution, review, planning, and reflection without losing boundaries.
+
+Scenario:
+Use when a conversation changes from brainstorming to implementation, from execution to review, or from review to handoff.
+
+Instructions:
+- Work only from the material I provide.
+- Follow these steps:
+  1. Confirm the old mode and new mode in plain language.
+  2. Carry forward only the context needed for the new mode.
+  3. Restate what actions are allowed and forbidden.
+  4. Name the first output expected in the new mode.
+- Do not claim to understand my private business beyond the provided context.
+- Return the expected output shape below.
+
+Material:
+[paste redacted material here]
+```
+
+## Expected output
+
+- Mode change
+- Allowed actions
+- Forbidden actions
+- Context carried forward
+- First output
+
+## Failure modes
+
+- Continuing to execute while pretending to review.
+- Losing authorization boundaries after a role switch.
+- Dragging irrelevant old context into a focused task.
+
+## Example
+
+Switch from execution to guard review: stop editing, inspect the changed files, compare against acceptance, and report findings first.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/prompts/profile-creation.md

@@ -0,0 +1,66 @@
+# Profile creation
+
+Purpose: Create a reusable collaboration profile from a redacted user description.
+
+## Scenario
+
+Use when a user is starting a new AI workspace and wants future sessions to know how to collaborate without storing private secrets.
+
+## Input requirements
+
+- Redacted description of the user's work and preferred feedback style.
+- Known boundaries: actions the assistant must not take without consent.
+- Examples of useful and unhelpful assistant behavior.
+
+## Operating steps
+
+1. Extract stable preferences only; ignore one-off task facts.
+2. Separate communication style, decision rules, safety boundaries, and update triggers.
+3. Ask no more than three questions if a boundary is ambiguous.
+4. Mark any inferred preference as provisional.
+
+## Copy-paste prompt
+
+```text
+You are helping me with profile creation in a local-first AI collaboration workspace.
+
+Task: Create a reusable collaboration profile from a redacted user description.
+
+Scenario:
+Use when a user is starting a new AI workspace and wants future sessions to know how to collaborate without storing private secrets.
+
+Instructions:
+- Work only from the material I provide.
+- Follow these steps:
+  1. Extract stable preferences only; ignore one-off task facts.
+  2. Separate communication style, decision rules, safety boundaries, and update triggers.
+  3. Ask no more than three questions if a boundary is ambiguous.
+  4. Mark any inferred preference as provisional.
+- Do not claim to understand my private business beyond the provided context.
+- Return the expected output shape below.
+
+Material:
+[paste redacted material here]
+```
+
+## Expected output
+
+- Profile summary
+- Collaboration defaults
+- Hard boundaries
+- Review and challenge preferences
+- When to update this profile
+
+## Failure modes
+
+- Turning the profile into a biography.
+- Saving secrets, customer names, local paths, or raw private conversations.
+- Treating a single emotional moment as a permanent preference.
+
+## Example
+
+Input: 'I build prototypes alone and hate vague reassurance.' Output: 'Use direct risk calls, short options, and evidence labels; do not make purchases or publish without explicit consent.'
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/prompts/profile-refinement.md

@@ -0,0 +1,66 @@
+# Profile refinement
+
+Purpose: Update an existing profile with only stable new preferences.
+
+## Scenario
+
+Use after several sessions reveal a repeated working preference or a profile rule is causing friction.
+
+## Input requirements
+
+- Current profile card.
+- New evidence from at least one recent task.
+- Whether the user explicitly confirmed the new preference.
+
+## Operating steps
+
+1. Compare new evidence against the existing profile.
+2. Classify each candidate as stable, task-specific, contradictory, or unsafe to store.
+3. Preserve older rules unless there is clear replacement evidence.
+4. Return a patch-style update instead of rewriting the whole profile.
+
+## Copy-paste prompt
+
+```text
+You are helping me with profile refinement in a local-first AI collaboration workspace.
+
+Task: Update an existing profile with only stable new preferences.
+
+Scenario:
+Use after several sessions reveal a repeated working preference or a profile rule is causing friction.
+
+Instructions:
+- Work only from the material I provide.
+- Follow these steps:
+  1. Compare new evidence against the existing profile.
+  2. Classify each candidate as stable, task-specific, contradictory, or unsafe to store.
+  3. Preserve older rules unless there is clear replacement evidence.
+  4. Return a patch-style update instead of rewriting the whole profile.
+- Do not claim to understand my private business beyond the provided context.
+- Return the expected output shape below.
+
+Material:
+[paste redacted material here]
+```
+
+## Expected output
+
+- Keep unchanged
+- Add
+- Revise
+- Do not store
+- Open confirmation question
+
+## Failure modes
+
+- Overwriting the profile because one task went badly.
+- Adding private operational detail as if it were a collaboration preference.
+- Hiding uncertainty by merging contradictory preferences.
+
+## Example
+
+Current profile says 'ask before execution.' New evidence says user now gives task-level authorization for explicit implementation requests. Output a narrow revision with the exact trigger.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/prompts/project-context-packaging.md

@@ -0,0 +1,113 @@
+# Project context packaging
+
+Purpose: Compress a messy task into facts, boundaries, assumptions, risks, and open questions.
+
+## Scenario
+
+Use when a task spans files, sessions, tools, or decisions and a new assistant would otherwise start by guessing.
+
+## Input requirements
+
+- Goal in the user's words.
+- Current state and relevant artifacts.
+- Constraints, non-goals, facts, assumptions, blockers, and known risks.
+
+## Operating steps
+
+1. Name the task boundary first — goal plus explicit non-goals — before summarizing any detail. A package without a boundary invites the receiver to expand scope into whatever looks interesting.
+2. Compress the situation into five buckets, not a narrative: FACTS (verified, with the evidence or file reference), BOUNDARIES (in scope vs out of scope), ASSUMPTIONS (believed but unverified, labeled as such), RISKS (what could go wrong), OPEN QUESTIONS (what is genuinely undecided). Split fact from assumption and decision from preference; do not let a confident sentence blur the two.
+3. Climb the purpose chain before fixing the delivery shape: do not stop at 'this task belongs to category X'. Ask what the owner will ultimately DO with the result — decide something, unblock a downstream step, cut review cost — because the end use is what sets the right granularity, depth, and format. A deliverable that maps to a category but serves no actual use is a compliance document, not a usable tool. If you cannot answer the end use, stop and re-define the task rather than packaging detail around a goal you have not pinned.
+4. Frame the next-step options as a menu, not the map: it is your view of what comes next, and you may have missed, misordered, or mis-scoped an item. Mark which options are well-grounded and which are guesses, and invite the receiver to find an unlisted option D or E.
+5. Hand the receiver an explicit first-round judgment to run before executing: (1) what is this task actually for — restate the goal, the current sub-task, and the completion bar; (2) is this option list exhaustive — what did I miss; (3) is there an unlisted item that serves the main line versus one that would hijack it? An option list accepted without questioning is an option list whose blind spots get inherited.
+6. End with one concrete next action and the smallest missing question — the single piece of information that, once answered, would most change what the receiver should do.
+
+## Copy-paste prompt
+
+```text
+You are helping me with project context packaging in a local-first AI collaboration workspace.
+
+Task: Compress a messy task into facts, boundaries, assumptions, risks, and open questions.
+
+Trigger:
+Use at the start of any task that will cross a boundary — span multiple files, sessions, or tools, get handed to a different assistant, or be resumed later — and where a new assistant starting cold would otherwise begin by guessing. Package the context BEFORE the next assistant acts, so it inherits a boundary instead of a transcript.
+
+Do not use when:
+Skip the full packaging for a single-step task with one obvious goal and no state worth transferring, or a quick fact lookup you will act on yourself in the same breath. A full facts/boundaries/assumptions/risks/open-questions package for a one-line ask is overhead the receiver does not need, and ceremony with no payoff trains people to skip packaging when the task is actually tangled.
+
+Input:
+The goal in the owner's own words. The current state and the artifacts that matter (files, links, prior decisions). The constraints and the explicit non-goals. What is known as fact versus assumed. The blockers and known risks. And, honestly, what you may have left off the list — because the biggest risk in a handoff is the option the author never wrote down.
+
+Process:
+1. Name the task boundary first — goal plus explicit non-goals — before summarizing any detail. A package without a boundary invites the receiver to expand scope into whatever looks interesting.
+2. Compress the situation into five buckets, not a narrative: FACTS (verified, with the evidence or file reference), BOUNDARIES (in scope vs out of scope), ASSUMPTIONS (believed but unverified, labeled as such), RISKS (what could go wrong), OPEN QUESTIONS (what is genuinely undecided). Split fact from assumption and decision from preference; do not let a confident sentence blur the two.
+3. Climb the purpose chain before fixing the delivery shape: do not stop at 'this task belongs to category X'. Ask what the owner will ultimately DO with the result — decide something, unblock a downstream step, cut review cost — because the end use is what sets the right granularity, depth, and format. A deliverable that maps to a category but serves no actual use is a compliance document, not a usable tool. If you cannot answer the end use, stop and re-define the task rather than packaging detail around a goal you have not pinned.
+4. Frame the next-step options as a menu, not the map: it is your view of what comes next, and you may have missed, misordered, or mis-scoped an item. Mark which options are well-grounded and which are guesses, and invite the receiver to find an unlisted option D or E.
+5. Hand the receiver an explicit first-round judgment to run before executing: (1) what is this task actually for — restate the goal, the current sub-task, and the completion bar; (2) is this option list exhaustive — what did I miss; (3) is there an unlisted item that serves the main line versus one that would hijack it? An option list accepted without questioning is an option list whose blind spots get inherited.
+6. End with one concrete next action and the smallest missing question — the single piece of information that, once answered, would most change what the receiver should do.
+
+Output shape:
+- Goal and boundary: the goal in one line, with explicit non-goals.
+- Facts: verified items, each with its evidence or file reference.
+- Assumptions: believed-but-unverified items, labeled, kept separate from facts.
+- Risks: what could go wrong, ordered by impact.
+- Open questions: what is genuinely undecided, with the smallest missing question called out.
+- End-use chain: what the owner ultimately does with the result, and how that sets the delivery shape.
+- Option menu (not the map): 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 a serving-vs-hijacking D or E).
+- Next action: one concrete first step the receiver can take from this package alone.
+
+Pass bar (do not pass unless all hold):
+- The task boundary — goal plus explicit non-goals — is stated before any detail, so scope cannot quietly expand.
+- Facts and assumptions are in separate buckets, and every assumption is labeled rather than dressed as fact.
+- The end-use chain is answered: what the owner finally does with the result is named, not just which category the task falls under.
+- The option list is framed as a menu with missing or guessed items flagged, not presented as the complete set of next steps.
+- There is one concrete next action and one smallest-missing-question, and a cold reader could continue from this package without the original chat.
+
+Reject bar (send back if any holds):
+- The package is a replayed transcript or a story of what happened, not a compressed boundary a stranger can act on.
+- Non-goals are missing, so the receiver is free to expand scope into whatever looks interesting.
+- An assumption is stated as a fact with no label and no evidence, and a later step would rest on it.
+- The task is mapped to a clause or category but the owner's ultimate use is never named, so the delivery granularity is set by guesswork.
+- The option list is handed over as the whole map, inviting the receiver to inherit the author's blind spots instead of testing for a missing D or E.
+
+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 state
+- Relevant artifacts
+- Constraints and non-goals
+- Facts
+- Assumptions
+- Risks
+- Open questions
+- Next action
+
+## Counter-example
+
+Synthetic: a handoff package says 'finish the onboarding work; options are A polish the copy, B add a tooltip, C reorder the steps; next: do A.' A cold receiver that runs the first-round check instead of grabbing A asks question one — what is this actually for — and finds the real end use is 'get more new users to create their first note', not 'make the copy nicer'. Question two exposes that the author never listed the fact that three testers abandoned before the first note even loaded — an unlisted item D (the first screen is broken) that the copy options would never fix. The package had mapped the task to the category 'onboarding copy' but never to the owner's actual use, so the polished menu would have shipped prettier words on a screen users never reached.
+
+## Failure modes
+
+- Dumping a transcript instead of packaging context.
+- Omitting non-goals and letting scope expand.
+- Losing evidence links or file references needed for review.
+- Handing over the option list as the whole map, so the receiver inherits whatever the author forgot.
+- Naming which clause or category the task belongs to but never what the owner ultimately does with the result.
+
+## Example
+
+Messy input says 'fix onboarding, maybe pricing too, users are confused.' Output separates onboarding as the current scope and pricing as a non-goal until evidence changes.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/prompts/red-team-challenge.md

@@ -0,0 +1,106 @@
+# Red-team challenge
+
+Purpose: Attack a plan or artifact from the angle most likely to make it fail.
+
+## Scenario
+
+Use before high-risk decisions, public release, data migration, force overwrite, or claims that could mislead users.
+
+## Input requirements
+
+- Plan or artifact to challenge.
+- What failure would be expensive, embarrassing, unsafe, or irreversible.
+- Known assumptions and skipped checks.
+
+## Operating steps
+
+1. Take the attacker's stance, not the helper's. Your job is to make the thing fail, get abused, or get bypassed — and to show it, not to politely suggest improvements. 'Consider adding validation' is not a red-team finding; 'here is the exact input that deletes the user's files' is.
+2. Name the single most damaging plausible failure first, in concrete terms (what is lost, who is harmed, can it be undone). Lead with the worst case so a reader feels the stakes before the details.
+3. Walk real abuse and bypass paths, not exotic ones: the ordinary user who clicks the destructive button by accident or misreads the prompt; the insider who takes the convenient shortcut around the safeguard; the automated or repeated call that hits an unhandled edge; the malformed or hostile input; the missing rollback when a step fails halfway; the privacy or secret that leaks through an error message, a log, or an example. Prefer the mundane data-loss path over the cinematic one.
+4. For each path, try to actually break it on the provided material and show the trigger — the exact input, sequence, or condition — and the resulting damage. If you cannot fully demonstrate it from what was given, say what specific evidence or test would confirm or kill the attack.
+5. Separate fatal flaws (must fix before this ships) from acceptable trade-offs (real but tolerable, named as residual risk). Do not inflate every nit into a blocker; that buries the one attack that actually matters.
+6. End with the smallest concrete change or test that closes the most dangerous path — the minimal mitigation, not a rewrite.
+
+## Copy-paste prompt
+
+```text
+You are helping me with red-team challenge in a local-first AI collaboration workspace.
+
+Task: Attack a plan or artifact from the angle most likely to make it fail.
+
+Trigger:
+Use before high-stakes, hard-to-reverse moves: a public release, a data migration, a force-overwrite or destructive flag, a security or auth change, a permissions or payment path, or any claim that could mislead users if it were wrong. Run it when you need to know how the thing breaks, not whether it is nice.
+
+Do not use when:
+Skip it on low-stakes, easily reversible work, or where the worst case is trivial and self-correcting: a wording tweak, a scratch script, a change you can undo in one step with no data or trust at risk. A full attack pass on trivial work is theater, and theater with no payoff trains people to ignore the red team when the stakes are real.
+
+Input:
+The plan or artifact to attack. What a failure would cost — money, data loss, a privacy leak, user harm, reputational damage, an irreversible state. The acceptance criteria it claims to meet. The assumptions the author is leaning on and the checks they admit they skipped. Who can touch it: end users, insiders, automated callers, a future maintainer who forgot the context.
+
+Process:
+1. Take the attacker's stance, not the helper's. Your job is to make the thing fail, get abused, or get bypassed — and to show it, not to politely suggest improvements. 'Consider adding validation' is not a red-team finding; 'here is the exact input that deletes the user's files' is.
+2. Name the single most damaging plausible failure first, in concrete terms (what is lost, who is harmed, can it be undone). Lead with the worst case so a reader feels the stakes before the details.
+3. Walk real abuse and bypass paths, not exotic ones: the ordinary user who clicks the destructive button by accident or misreads the prompt; the insider who takes the convenient shortcut around the safeguard; the automated or repeated call that hits an unhandled edge; the malformed or hostile input; the missing rollback when a step fails halfway; the privacy or secret that leaks through an error message, a log, or an example. Prefer the mundane data-loss path over the cinematic one.
+4. For each path, try to actually break it on the provided material and show the trigger — the exact input, sequence, or condition — and the resulting damage. If you cannot fully demonstrate it from what was given, say what specific evidence or test would confirm or kill the attack.
+5. Separate fatal flaws (must fix before this ships) from acceptable trade-offs (real but tolerable, named as residual risk). Do not inflate every nit into a blocker; that buries the one attack that actually matters.
+6. End with the smallest concrete change or test that closes the most dangerous path — the minimal mitigation, not a rewrite.
+
+Output shape:
+- Worst plausible failure: the single most damaging realistic outcome, stated concretely.
+- Attack paths: each with its trigger (exact input / sequence / condition) and the damage it causes.
+- How it gets abused or bypassed: the accidental-user, insider-shortcut, and automated-edge angles, not just the malicious outsider.
+- Evidence gaps: what could not be fully demonstrated and the exact test that would confirm or kill each attack.
+- Fatal vs tolerable: which findings block shipping and which are named residual risk.
+- Smallest mitigation: the minimal change or test that closes the most dangerous path.
+
+Pass bar (do not pass unless all hold):
+- The worst-case failure is named first and in concrete, this-is-what-is-lost terms.
+- At least one attack is shown with its actual trigger and damage, not phrased as a gentle suggestion.
+- Accidental-misuse and insider-shortcut paths are covered, not only deliberate outsider attacks.
+- Mundane data-loss and rollback gaps are checked, not skipped in favor of exotic threats.
+- Findings are split into fatal vs tolerable, and each fatal one comes with the smallest mitigation that closes it.
+
+Reject bar (send back if any holds):
+- The output is theatrical or vague ('an attacker could do bad things') with no concrete trigger.
+- It only offers polite improvements and never demonstrates or pins a real break.
+- It invents impossible or exotic threats while missing the obvious data-loss, overwrite, or leak path.
+- It challenges the idea in general but never tests the exact acceptance criteria or the destructive flag in question.
+- Every finding is rated a blocker, so the one attack that actually matters is buried in nits.
+
+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
+
+- Worst plausible failure
+- Attack paths
+- Evidence gaps
+- Required mitigations
+- Acceptable residual risk
+
+## Counter-example
+
+Synthetic: a CLI ships a `--force` flag that re-creates a workspace directory. A gentle review says 'consider warning the user before overwriting.' The red-team stance instead shows the break: run `init --force` in a directory where the user also keeps their own notes file, and the worst case is those user-created files are deleted with no backup and no undo. The trigger is concrete (force flag plus a non-empty target), the damage is irreversible data loss, the abuse path is the ordinary user who did not realize the directory was shared, and the smallest mitigation is to move the existing workspace to a timestamped backup before recreating it and to refuse on unexpected extra files — not a rewrite.
+
+## Failure modes
+
+- Being theatrical instead of specific.
+- Inventing impossible threats while missing mundane data-loss risks.
+- Challenging the idea but not the exact acceptance criteria.
+- Giving gentle suggestions ('consider adding a check') instead of demonstrating an actual break.
+- Attacking only malicious outsiders while ignoring the ordinary user who clicks the wrong thing and the insider who takes a convenient shortcut.
+
+## Example
+
+For a --force option, the red team asks whether user-created files inside the target directory survive or are backed up.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/prompts/rule-update-proposal.md

@@ -0,0 +1,114 @@
+# Rule update proposal
+
+Purpose: Suggest a new rule from repeated evidence without silently changing the system.
+
+## Scenario
+
+Use when the same failure appears across tasks and may deserve a reusable rule, checklist item, or template change.
+
+## Input requirements
+
+- Observed failures or repeated friction.
+- Evidence count and examples.
+- Proposed rule text.
+- Scope, exceptions, and rollback condition.
+
+## Operating steps
+
+1. Prove the pattern is repeated before proposing anything. State the distinct instances and their dates or contexts; if you have only one, stop and label it a watch-item, not a rule. One anecdote does not earn standing doctrine.
+2. Write the rule in operational, checkable language — a reader must be able to tell whether it was followed. 'Be more careful with releases' is uncheckable; 'before labeling a release candidate, install the packed package in a clean temp directory and confirm it runs' is.
+3. Answer the lifecycle question that every addition must carry: what does this rule REPLACE, RETIRE, or DEMOTE? A rule that adds to the set without removing or superseding anything is bloat until proven otherwise. If it truly adds net-new coverage, say what it is net-new over and why nothing existing covers it.
+4. Specify the full lifecycle in five fields, not just the trigger: (1) TRIGGER — when the rule is read or applied; (2) REPLACES — the rule it supersedes, demotes, or makes redundant; (3) ACCEPTANCE — what observable evidence would show it is actually helping; (4) ARCHIVE CONDITION — how long unused or how much drift before it is demoted or retired; (5) REVIEW WINDOW — when its keep/cut decision gets revisited. A rule with no archive condition and no review window is a rule that can only accumulate.
+5. Judge the proposal on net benefit, not on the act of adding or cutting. The test is (expected benefit minus carrying cost and risk), and you only adopt the clearly-positive, low-downside cases; when the benefit is uncertain, do not add it. Equally, do not cut for the sake of looking lean — a dormant rule with no harm can stay; removing a negative is the only subtraction that is automatically worth it.
+6. Before proposing any removal or merge, answer the three subtraction questions: (1) does any main-line capability drop if this goes; (2) is the path to bring it back clear; (3) how is a wrong cut rolled back? If those are not answered, the cut is not ready.
+7. Present it as a proposal for sign-off, never a silent change to shared behavior. Name the approver and the rollback condition; staging waits for a human to file it.
+
+## Copy-paste prompt
+
+```text
+You are helping me with rule update proposal in a local-first AI collaboration workspace.
+
+Task: Suggest a new rule from repeated evidence without silently changing the system.
+
+Trigger:
+Use when the same failure or friction has shown up across multiple tasks and may deserve a standing rule, checklist item, or template change — or when you are weighing whether to add, merge, demote, or retire a rule. The unit of justification is a repeated pattern, not a single bad moment.
+
+Do not use when:
+Do not run this to mint a rule from one incident, and do not invent a rule just to feel productive — an unjustified standing rule is worse than none, because every future task then has to obey it and read past it. Skip it for a one-off slip with an obvious local fix, or a throwaway preference that will not recur. If the only evidence is a single anecdote, the honest output is 'not yet a rule; watch for recurrence', not a new line in the rulebook.
+
+Input:
+The observed failures or friction, with how many distinct times each occurred and a concrete example of each — enough to show a pattern, not one story. The exact rule text being proposed, in operational language. Where it would apply and where it must not. Which existing rule it would replace, demote, or make redundant. The cost of carrying it (added reading, added ceremony, conflict with other rules). And who can approve a change to shared behavior.
+
+Process:
+1. Prove the pattern is repeated before proposing anything. State the distinct instances and their dates or contexts; if you have only one, stop and label it a watch-item, not a rule. One anecdote does not earn standing doctrine.
+2. Write the rule in operational, checkable language — a reader must be able to tell whether it was followed. 'Be more careful with releases' is uncheckable; 'before labeling a release candidate, install the packed package in a clean temp directory and confirm it runs' is.
+3. Answer the lifecycle question that every addition must carry: what does this rule REPLACE, RETIRE, or DEMOTE? A rule that adds to the set without removing or superseding anything is bloat until proven otherwise. If it truly adds net-new coverage, say what it is net-new over and why nothing existing covers it.
+4. Specify the full lifecycle in five fields, not just the trigger: (1) TRIGGER — when the rule is read or applied; (2) REPLACES — the rule it supersedes, demotes, or makes redundant; (3) ACCEPTANCE — what observable evidence would show it is actually helping; (4) ARCHIVE CONDITION — how long unused or how much drift before it is demoted or retired; (5) REVIEW WINDOW — when its keep/cut decision gets revisited. A rule with no archive condition and no review window is a rule that can only accumulate.
+5. Judge the proposal on net benefit, not on the act of adding or cutting. The test is (expected benefit minus carrying cost and risk), and you only adopt the clearly-positive, low-downside cases; when the benefit is uncertain, do not add it. Equally, do not cut for the sake of looking lean — a dormant rule with no harm can stay; removing a negative is the only subtraction that is automatically worth it.
+6. Before proposing any removal or merge, answer the three subtraction questions: (1) does any main-line capability drop if this goes; (2) is the path to bring it back clear; (3) how is a wrong cut rolled back? If those are not answered, the cut is not ready.
+7. Present it as a proposal for sign-off, never a silent change to shared behavior. Name the approver and the rollback condition; staging waits for a human to file it.
+
+Output shape:
+- Problem pattern: the repeated failure, stated once.
+- Evidence: the distinct instances with dates or contexts — enough to show repetition, not a single anecdote.
+- Proposed rule: operational, checkable text.
+- Replaces / retires / demotes: what existing rule this supersedes, or an explicit argument for why it is net-new.
+- Lifecycle fields: trigger / replaces / acceptance / archive condition / review window.
+- Net-benefit call: expected benefit versus carrying cost and risk, and why it is clearly positive (or why it should wait).
+- Subtraction check (for any removal or merge): capability-loss / recovery-path / rollback answered.
+- Scope and exceptions: where it applies and where it must not.
+- Review owner and rollback condition: who approves and how a wrong call is undone.
+
+Pass bar (do not pass unless all hold):
+- The pattern is shown as repeated across distinct instances, not generalized from one incident.
+- The rule is written so a reader can mechanically tell whether it was followed.
+- The proposal names what it replaces, retires, or demotes — or argues explicitly why it is net-new — so the rule set is not just growing.
+- All five lifecycle fields are present, including an archive condition and a review window, so the rule can later be cut, not only kept.
+- The decision rests on net benefit, and any removal answers the capability-loss / recovery-path / rollback questions rather than cutting to look lean.
+
+Reject bar (send back if any holds):
+- A standing rule is proposed from a single anecdote with no evidence of recurrence.
+- The rule text is a vibe ('be more careful', 'handle releases better') that no one can check compliance against.
+- The addition names nothing it replaces, retires, or demotes, and makes no case for being net-new — pure accumulation.
+- Lifecycle fields are missing, especially the archive condition and review window, so the rule can only ever be added and never retired.
+- A removal or merge is proposed without answering whether a main-line capability drops, how to recover it, or how to roll back a wrong cut — or a harmless dormant rule is cut purely for tidiness.
+
+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
+
+- Problem pattern
+- Evidence
+- Proposed rule
+- Scope
+- Exceptions
+- Review owner
+- Rollback condition
+
+## Counter-example
+
+Synthetic: an assistant proposes a brand-new governance rule after one release slipped, adds it to the rulebook, and names nothing it supersedes. Reviewed under this prompt, two faults surface. First, the lifecycle question is unanswered — the rule replaces, retires, and demotes nothing, so it is pure accumulation; and it carries no archive condition or review window, meaning it can only ever be added to the pile. Second, the evidence is a single incident, below the repeated-pattern bar, so the honest output is a watch-item, not doctrine. A revealing real-world tell of this failure mode: a cleanup round that set out to 'add a subtraction metric' ended up adding several new items and removing zero — proof that knowing you should subtract is not the same as the system actually subtracting. The disciplined proposal waits for a second and third recurrence, writes the rule as a checkable temp-install step, states that it replaces an older vaguer 'test before release' note, and attaches an archive condition and a named approver before anything lands.
+
+## Failure modes
+
+- Creating governance bloat from one incident.
+- Silently changing shared behavior without approval.
+- Writing a rule so vague that it cannot be checked.
+- Proposing an addition without naming what it replaces, retires, or demotes, so the rule set only ever grows.
+- Cutting a harmless, dormant rule purely to look lean, with no check on what capability is lost or how to roll back.
+
+## Example
+
+After three release tasks missed packed-package smoke tests, propose a release checklist item requiring temp install before candidate labeling.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.