mustflow 2.116.4 → 2.117.1

package/templates/default/locales/en/.mustflow/skills/agent-memory-context-governance-review/SKILL.md

@@ -0,0 +1,163 @@
+---
+mustflow_doc: skill.agent-memory-context-governance-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: agent-memory-context-governance-review
+description: Apply this skill when LLM agents or assistants create, consolidate, retrieve, inject, update, expire, supersede, export, or delete persistent user memory, project memory, conversation history, summaries, structured task state, or long-context evidence and the risk is stale authority, semantic drift, privacy leakage, prompt injection, cross-scope contamination, deletion failure, or memory-quality theater rather than ordinary object-memory lifetime.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.agent-memory-context-governance-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Agent Memory and Context Governance Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review persistent agent memory and long-task context as a scoped, versioned, revocable control plane rather than a bag of similar text. Current user instructions and authoritative systems remain the source of truth; memories, summaries, embeddings, and structured task state are derived inputs that must prove scope, provenance, freshness, access, and deletion before they can influence a response or tool decision.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- An LLM agent or assistant stores or retrieves user preferences, project decisions, personal facts, conversation facts, task history, tool results, summaries, embeddings, graph memories, episodic memories, or semantic memories across turns or sessions.
+- A change adds or edits memory extraction, consolidation, deduplication, conflict resolution, versioning, supersession, dormancy, expiry, retention, deletion, export, or user memory controls.
+- Long conversation or task history is assembled from fixed instructions, recent raw messages, structured current state, retrieved prior evidence, summaries, or a full-context fallback.
+- Memory retrieval uses semantic similarity, keyword search, time, project, tenant, user, domain, dependency, provenance, or access-control filters.
+- A memory can affect prompt authority, tool selection, tool arguments, personalization, recommendations, policy decisions, or external actions.
+- Memory quality, stale-memory use, cross-scope leakage, current-instruction override, deletion completeness, token cost, latency, or personalization benefit is evaluated or reported.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main risk is retained objects, listeners, timers, workers, handles, queues, caches, or process memory leaks; use `memory-lifetime-review`.
+- The task only assembles one non-persistent prompt or RAG context and no durable user or task memory is created; use `prompt-contract-quality-review`, `llm-token-cost-control-review`, or `rag-pipeline-triage` as appropriate.
+- The task only retrieves product or document knowledge from a search index; use `search-index-integrity-review`, `vector-search-integrity-review`, or `rag-pipeline-triage` unless retrieved personal or project memory changes the authority boundary.
+- The main risk is runtime agent planning, approval, tool execution, side effects, interrupt, or resume; use `agent-execution-control-review` and keep this skill as an adjunct only for the persistent memory boundary.
+- The task only records a bounded coding-task handoff or compacted restart point; use `restricted-handoff-resume`.
+- The task is generic privacy, retention, access control, or deletion with no LLM memory or context admission; use the narrower privacy, security, data-lifecycle, or deletion skill.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Memory-class ledger: explicit user fact, explicit preference, project decision, inferred preference candidate, session task state, tool observation, evidence cache, summary, embedding, graph edge, or another declared class; owner and intended use for each class.
+- Authority ledger: current user instruction, system or developer policy, repository or project contract, live database or tool state, persisted memory, derived summary, model inference, and how conflicts are resolved without letting a lower-authority memory become a command.
+- Record ledger: subject, type, value, scope, source reference, observed and recorded time, valid-from and valid-to bounds, confidence, sensitivity, lifecycle status, superseded record, review time, schema version, and fields intentionally omitted.
+- Lifecycle ledger: observed, candidate, confirmed, dormant, superseded, deleted, or repository-equivalent states; transitions, owners, activation evidence, expiry, revalidation, and terminal deletion behavior.
+- Context-assembly ledger: fixed contract, recent raw context, structured current state, retrieved evidence, summary layer, token budget, ordering, truncation, confidence, conflict behavior, and long-context fallback.
+- Retrieval ledger: hard scope and access filters, exact-key search, keyword search, semantic retrieval, time and dependency links, reranking, admission threshold, result limit, conflict handling, and no-result behavior.
+- Privacy and deletion ledger: sensitivity classes, consent, non-storable secret classes, encryption, retention, access logs, export, user inspection and correction, active store, embeddings, graph edges, summaries, caches, backups, tombstones, and re-extraction prevention.
+- Eval ledger: memory precision, required-memory recall, stale-memory use, invalid-memory rejection, current-instruction override, cross-user or cross-project leakage, memory-induced unsafe action, task outcome, user correction, deletion proof, token cost, and latency.
+- Relevant command-intent entries for lint, build, tests, docs, templates, release packaging, and mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the exclusions.
+- Current repository instructions, command contract, memory schema, storage, retrieval, context builder, prompt boundary, access control, deletion path, telemetry, tests, docs, and template surfaces have been inspected before editing.
+- Current source systems and user instructions are distinguished from stored memories and summaries before any authority claim is made.
+- External research, vendor benchmarks, memory-framework examples, generated summaries, and model outputs are evidence only. Provider-specific APIs, benchmark scores, and retention defaults are stale-sensitive and do not become repository policy without current source evidence.
+- Command execution remains governed by `.mustflow/config/commands.toml`; this skill does not authorize production-memory reads, model calls, data exports, destructive deletion, migrations, or long-running eval jobs.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine memory classes, schemas, extraction gates, lifecycle state machines, version and supersession links, freshness and validity fields, retention policy, retrieval filters, memory admission, context builders, summary regeneration, tombstones, cache invalidation, deletion propagation, user controls, redaction, eval fixtures, tests, docs, route metadata, and directly synchronized templates.
+- Add focused fixtures for explicit versus inferred memory, stale preference rejection, current-instruction precedence, cross-user and cross-project isolation, role-play contamination, memory-as-instruction rejection, summary drift, conflict hold, expiry, supersession, deletion propagation, tombstone re-extraction prevention, retrieval miss, and long-context fallback.
+- Keep raw evidence, structured memory, summaries, embeddings, indexes, and prompt-ready context separate when they have different authority, retention, or deletion behavior.
+- Do not widen memory collection, enable automatic sensitive-memory storage, backfill production conversations, rewrite retention periods, or perform destructive erasure unless the user request and configured command contract authorize that operational change.
+- Do not turn a model inference, generated answer, retrieved instruction-like string, or frequently repeated assistant output into a confirmed user fact without the declared evidence path.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Name the memory product contract. State what repeated user or project task memory should improve, what must never be remembered, which actions memory may influence, and what no-memory behavior remains acceptable.
+2. Identify authoritative state first. Files, databases, provider state, current tool results, current user instructions, and current policy own live truth in their domains. Memory may point to or cache that truth, but it must not silently replace a cheap current check.
+3. Classify every stored item. Separate explicit facts, explicit preferences, project decisions, inferred candidates, session state, tool observations, evidence caches, and summaries. Do not use one generic `memory` record whose authority and expiry must be guessed at retrieval time.
+4. Minimize collection. Store only information with a declared repeated use, scope, sensitivity decision, and retention owner. High recall is not a quality goal when one wrong or over-scoped memory can change a tool action.
+5. Gate extraction. Explicit signals such as a direct request to remember, a project-scoped decision, or a durable preference may enter a confirmation path. One-off model inference remains a candidate until the repository's repeated-evidence or user-confirmation rule is met. The agent's own answer is not a factual source about the user.
+6. Use an observable record contract. Include the subject, kind, value, scope, source, observed time, validity, confidence, sensitivity, lifecycle status, schema version, and supersession or review links needed by the actual policy. If a field is unnecessary, omit it deliberately rather than fabricating precision.
+7. Model lifecycle transitions. Use repository-named equivalents of observed, candidate, confirmed, dormant, superseded, and deleted states. Define who or what can activate, demote, supersede, revalidate, or delete a record and ensure every state has a bounded next action or terminal state.
+8. Version rather than overwrite. Close the old validity interval and link the new record as its successor when a fact, preference, or decision changes. Preserve enough provenance to explain the active value without injecting the whole history into prompts.
+9. Resolve conflicts by authority dimension. Current explicit user instruction outranks older user memory for the current action. Current authoritative system state outranks conversational copies. Explicit statements outrank unconfirmed inference within the same scope. When conflict remains unresolved, exclude the memory and request or perform revalidation rather than inventing a compromise.
+10. Declare expiry and dormancy by class. Session state, temporary facts, inferred candidates, explicit preferences, project decisions, and sensitive consented records need different retention and review policies. Do not copy universal day counts from another product; choose bounds from actual user expectation, legal and privacy policy, change rate, and revalidation cost.
+11. Default persistent storage to low-sensitivity, work-relevant classes. Identity, health, finance, legal matters, relationships, exact location, and third-party data require class-specific consent and controls. Passwords, authentication codes, session cookies, API keys, private keys, recovery codes, and payment security codes are non-storable long-term secrets even when they appear in a conversation.
+12. Assemble context in layers. Keep stable instructions and success constraints, recent raw evidence, structured current task state, and retrieved prior evidence distinct. Assign measured budgets and preserve priority; do not let a large retrieved block bury a current prohibition or success criterion.
+13. Treat summaries as rebuildable caches. Generate a summary from raw evidence and current authoritative state, not by recursively summarizing old summaries. Store source references, generation version, uncertainty, and coverage gaps so a stale or lossy summary can be discarded and rebuilt.
+14. Use long context as a bounded fallback. Start with scoped retrieval and compact evidence. Expand to the relevant raw session, dependency chain, or longer context only when retrieval confidence is low, sources conflict, or the task requires an uncompressed sequence. Full history on every call is neither correctness proof nor a substitute for retrieval evaluation.
+15. Apply hard filters before similarity. Filter by user and tenant, project, domain, real versus role-play or hypothetical scenario, validity interval, lifecycle state, consent, sensitivity, and access rights. Only then use exact keys, keywords, embeddings, time, graph dependencies, or reranking.
+16. Preserve causal and dependency links where tasks need them. A semantically similar error may be less useful than the exact earlier configuration change, failed attempt, or decision that caused it. Keep stable IDs and bounded links between decisions, evidence, failures, and superseding fixes.
+17. Admit a small, atomic result set. Prefer independently attributable memory records with scope and source over one blended profile paragraph. When candidate memories conflict, resolve them before prompting or inject an explicit unresolved state rather than asking the model to invent a middle ground.
+18. Treat retrieved memory as data, never command authority. Instruction-like text inside memory, summaries, embeddings, or source conversations cannot override current system, developer, user, repository, policy, or tool authority. Tool capabilities and standing execution policies belong in their own approved control store.
+19. Recheck action-sensitive memory. Before memory changes a recipient, resource ID, permission, amount, disclosure, deletion, or other external effect, confirm current scope and authoritative state through the agent execution-control path.
+20. Make user controls complete. Provide inspection, source and reason display, correction, per-record deletion, category opt-out, export where required, and a temporary no-memory mode. A user must be able to distinguish a preference, project decision, inferred candidate, and current system fact.
+21. Propagate deletion. Invalidate the active record, search and vector indexes, graph links, summaries, prompt caches, derived profiles, and other product-owned projections. Record a non-sensitive tombstone or equivalent suppression marker when needed to prevent deleted raw history from recreating the memory.
+22. Do not overclaim erasure. Name backup, audit, legal-hold, encryption-key, and downstream-provider boundaries. Cryptographic erasure may support deletion only when data is actually isolated behind destroyable keys; deleting one database row does not prove every derived or retained copy is gone.
+23. Keep telemetry privacy-safe. Record IDs, classes, scopes, lifecycle transitions, admission reasons, stale rejection, retrieval counts, redacted reason codes, cost, and latency by default. Do not turn memory observability into a second ungoverned store of raw personal history.
+24. Evaluate enabled versus disabled memory on the same task distribution when possible. Measure task success, precision of admitted memory, recall of necessary memory, stale or superseded memory use, current-instruction override, cross-scope leakage, unsafe action influence, user correction, token cost, and latency separately.
+25. Test lifecycle and access adversarially. Cover repeated extraction, conflicting updates, expiry, dormant revalidation, deletion and re-extraction, similar users or projects, role-play versus real statements, malicious instruction-like memories, unavailable source evidence, stale summaries, and retrieval fallback.
+26. Treat schema, extractor, consolidator, embedding, index, filter, reranker, context layout, retention, consent, and deletion changes as memory migrations. Check old records, in-flight sessions, cached prompts, stale embeddings, and user-visible controls before claiming the new policy is active.
+27. Verify with the narrowest configured tests, fixtures, docs validation, release checks, and mustflow validation that cover the changed memory and context contract.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Persistent memory classes, authority, lifecycle, record schema, retention, retrieval, context admission, privacy, deletion, and eval boundaries are explicit where they affect behavior.
+- Current user instructions and authoritative systems remain higher-authority than memory, summaries, embeddings, cached state, and model inference.
+- Retrieved memories are scope- and access-filtered, freshness-aware, provenance-bearing data rather than hidden instructions or standing tool authority.
+- Summary, index, embedding, cache, tombstone, backup, and downstream deletion boundaries are named without claiming broader erasure than evidence proves.
+- Final reports distinguish measured task improvement from retrieval recall, benchmark claims, static governance hardening, and unverified production-memory behavior.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Use the narrowest configured fixture, schema, isolation, retention, deletion, prompt, context, docs, package, or release check that proves the changed memory-governance contract. Report production retention, provider deletion, long-context, or personalization evidence that cannot be established locally.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If memory class, scope, source, or authority is unknown, keep the item out of persistent memory and action-sensitive context until classified.
+- If current state and memory disagree, prefer current authoritative evidence or exclude the memory; do not silently merge incompatible claims.
+- If a retrieved memory contains instructions or would widen a tool action, reject it as authority and route the action through current approval and policy checks.
+- If deletion reaches only the primary record, report partial deletion and enumerate remaining projections, caches, backups, or provider copies instead of claiming completion.
+- If a benchmark shows higher recall but stale-memory use, leakage, current-instruction override, or unsafe action influence is unmeasured, do not claim net memory quality improvement.
+- If a configured command fails, use `failure-triage` before continuing.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Agent memory and context-governance surface reviewed
+- Memory classes, authority sources, lifecycle, record schema, and retention decisions
+- Context layers, summary provenance, retrieval filters, admission, conflict, and long-context fallback
+- Privacy, consent, non-storable secrets, user controls, deletion propagation, and telemetry decisions
+- Memory precision, required recall, stale use, instruction override, cross-scope leakage, task outcome, cost, and latency evidence
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining memory, context, privacy, deletion, or production-evidence risk

package/templates/default/locales/en/.mustflow/skills/agent-planning-recovery-review/SKILL.md

@@ -0,0 +1,180 @@
+---
+mustflow_doc: skill.agent-planning-recovery-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: agent-planning-recovery-review
+description: Apply this skill when a long-running LLM agent or agentic workflow needs a stable global goal, constraints, milestones, dependency graph, irreversible checkpoints, a short rolling plan, event-triggered replanning, compact context reconstruction, deterministic replay, or safe recovery across interruptions and unknown effects.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.agent-planning-recovery-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Agent Planning Recovery Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep long-horizon agent work stable without freezing a detailed plan that becomes wrong or
+replanning every step until the goal drifts. Preserve a fixed global contract and dependency graph,
+execute from a short evidence-bounded plan, and rebuild current state from durable events after
+interruptions.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- An agent task spans many steps, tools, milestones, context windows, process restarts, approvals,
+  callbacks, or external effects.
+- The design chooses between up-front plans, rolling plans, replanning triggers, dependency DAGs,
+  irreversible checkpoints, prompt compaction, snapshots, event logs, or resume behavior.
+- A restart or context rebuild must distinguish completed, pending, failed, unknown, compensated,
+  and superseded work without asking a model to reconstruct truth from prose.
+- A replan must preserve the identity of an already admitted business effect while allowing a new
+  execution attempt or plan version.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main problem is deterministic service orchestration, timers, callbacks, saga state, or
+  compensation with no LLM planning; use `durable-workflow-orchestration`.
+- The main problem is generic run, attempt, checkpoint, effect, receipt, or replay truth; use
+  `execution-ledger-integrity-review`.
+- The main problem is tool authority, approval, capability, or side-effect risk inside one plan; use
+  `agent-execution-control-review`.
+- The main problem is persistent user memory or context admission; use
+  `agent-memory-context-governance-review`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Global contract: goal, non-goals, invariants, constraints, acceptance criteria, milestones,
+  dependency DAG, risk limits, irreversible checkpoints, stop conditions, and human owner.
+- Rolling-plan ledger: plan ID and version, current horizon, selected steps, dependency and evidence
+  for each step, expected observation, effect class, approval boundary, and replan trigger.
+- Event contract: workflow ID, sequence, event type and schema version, plan and step IDs, effect and
+  attempt IDs, causation and correlation IDs, payload reference, authoritative time, and redaction.
+- Projection contract: reducer version, snapshot schema, cursor, rebuild procedure, consistency rule,
+  unknown-effect set, derived prompt view, and artifact references.
+- Recovery contract: replay boundary, pending and UNKNOWN reconciliation, lease or fence, version
+  compatibility, safe replan point, compensation owner, and manual-review state.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Define the authoritative business goal and irreversible effects before selecting a planning
+  algorithm or context size.
+- Treat prompt text, summaries, and model reasoning as temporary views, not durable workflow truth.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize live
+  workers, background loops, model calls, external effects, or production replay.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine global-plan schemas, milestone DAGs, rolling-plan records, replan triggers, event
+  envelopes, reducers, projections, snapshots, prompt-view builders, effect identity, recovery,
+  reconciliation, tests, docs, route metadata, and synchronized templates.
+- Move state derivation, dependency checks, event ordering, effect reconciliation, and invariant
+  validation into deterministic code where possible.
+- Do not persist free-form chain-of-thought as workflow state or require it for replay.
+- Do not let a replan create a second effect identity for the same admitted business intent.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Freeze the global contract, not the detailed route. Keep goal, invariants, constraints,
+   acceptance criteria, milestone DAG, irreversible checkpoints, budgets, and stop conditions stable
+   until a higher-authority change explicitly versions them.
+2. Plan only to the next meaningful uncertainty boundary. Choose the rolling horizon from the next
+   unknown observation, dependency uncertainty, irreversible effect, approval point, context budget,
+   and recovery cost. Do not copy a universal step count or horizon formula.
+3. Give each planned step a precondition, expected observation, effect class, verification, and
+   completion predicate. Omit speculative detail that depends on an observation not yet available.
+4. Replan on declared events, not on every step and not only on catastrophic failure. Trigger when
+   observed state diverges from the plan, a new unknown appears, a tool fails or returns UNKNOWN, a
+   milestone completes, an invariant changes, or the next step crosses an irreversible boundary.
+5. Keep one append-only event stream authoritative. Record business intent and observed facts with
+   ordered sequence and schema version. Derive snapshots, dashboards, summaries, and prompt context
+   from the stream rather than editing them as competing truth.
+6. Separate identifiers:
+   - keep `workflow_id` stable for the business workflow;
+   - identify the logical planned unit with `step_id` and the plan revision with `plan_id` or
+     `plan_version`;
+   - keep `effect_id` stable across replans for the same business intent;
+   - create a new `attempt_id` for each execution try.
+7. Persist effect intent before commitment. Bind the effect to tenant, actor, target, operation type,
+   canonical request fingerprint, approval, and policy. Use durable uniqueness and idempotent result
+   replay; route duplicate and stale-write detail to `idempotency-integrity-review`.
+8. Treat transport timeout and process loss as UNKNOWN until reconciled. Do not let a replan infer
+   failure and issue a second payment, email, publication, mutation, or other side effect.
+9. Build snapshots as disposable projections. Store the stream cursor and reducer version, verify
+   snapshot integrity, and support rebuilding from the canonical event stream. Use snapshots for
+   speed, never as an irreplaceable source of truth.
+10. Rebuild prompt context as a temporary view. Include the global goal and invariants, current
+    verified snapshot, rolling plan, relevant verified facts, pending and UNKNOWN effects, recent
+    failures, and artifact references. Exclude raw logs, obsolete plans, huge tool output, duplicate
+    history, secrets, and free-form reasoning.
+11. Resume deterministically before invoking a model. Load the compatible reducer, replay events,
+    verify sequence and snapshot cursor, reacquire ownership with a lease or fence, and reconcile
+    pending or UNKNOWN effects. Only then create a new plan revision.
+12. Make compensation a new idempotent effect linked to the original effect. Preserve why exact
+    rollback is unavailable and prevent duplicate compensation after retries or replans.
+13. Keep external delivery reliable. When durable state and message publication are separate, use a
+    transactional outbox or equivalent convergence boundary and idempotent consumers.
+14. Test plan drift and recovery, not only happy-path planning. Cover new evidence, tool failure,
+    milestone transition, irreversible checkpoint, crash before and after effect commitment,
+    timeout with unknown outcome, replay under a compatible reducer, incompatible schema, stale
+    owner, replan with stable effect ID, duplicate attempt, and compensation retry.
+15. Route generic durable callbacks, timers, saga state, and compensation sequencing to
+    `durable-workflow-orchestration`; route event and receipt truth to
+    `execution-ledger-integrity-review`; route memory lifecycle to
+    `agent-memory-context-governance-review`.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The global contract remains stable while rolling plans are short, evidence-bounded, and versioned.
+- Replanning is event-triggered and preserves admitted effect identity.
+- Append-only events are authoritative; snapshots and prompt context are rebuildable projections.
+- Resume performs deterministic replay and effect reconciliation before model planning or mutation.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and `mustflow_check`.
+Do not infer raw workflow replay, queue, database, model, worker, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the event stream has a sequence gap or incompatible schema, stop automatic resume and preserve
+  the last verified cursor.
+- If an effect outcome is UNKNOWN, reconcile authoritative external state before replan or retry.
+- If the reducer needs a model or external call, reject it as nondeterministic recovery logic.
+- If a plan change would widen the goal, constraints, permissions, or irreversible effect set,
+  require a new global-contract version and the appropriate approval owner.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Global contract, milestones, DAG, and irreversible checkpoints
+- Rolling horizon and event-triggered replan decision
+- Event, projection, snapshot, prompt-view, and identifier contracts
+- Resume, reconciliation, idempotency, outbox, and compensation findings
+- Recovery tests and evidence level
+- Command intents run and skipped checks
+- Remaining agent-planning recovery risk

package/templates/default/locales/en/.mustflow/skills/agent-release-bundle-rollout-review/SKILL.md

@@ -0,0 +1,181 @@
+---
+mustflow_doc: skill.agent-release-bundle-rollout-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: agent-release-bundle-rollout-review
+description: Apply this skill when an LLM agent's model, settings, rendered prompts, examples, tool schemas, adapters, policy, retrieval, memory, runtime, or evaluator changes must be packaged as one immutable behavior release and promoted through replay, shadow, canary, staged rollout, rollback, or emergency restriction without changing in-flight behavior unpredictably.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.agent-release-bundle-rollout-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Agent Release Bundle Rollout Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Release agent behavior as an attributable, immutable unit. Prevent a moving model alias, prompt,
+tool contract, policy, retrieval index, runtime, or evaluator from changing one automation path
+silently while it is running or while its result is being compared with another version.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- An agent behavior change includes a model or generation setting, rendered prompt, example set,
+  tool schema or adapter, external policy, retrieval or memory configuration, runtime dependency,
+  evaluator, or eval dataset.
+- A candidate agent version needs offline replay, shadow execution, canary exposure, staged
+  promotion, stable-pointer movement, rollback, or emergency capability restriction.
+- A rollout claim depends on cohort assignment, SLO gates, control comparison, whole-task
+  observation, side-effect suppression, compatibility, or per-version attribution.
+- Several automations consume shared prompts, models, tool definitions, policies, indexes, or
+  runtime libraries and a global change could create correlated failures.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only deploys generic servers, workers, containers, migrations, configuration, or feature
+  flags with no agent-behavior bundle; use `deployment-rollout-safety-review`.
+- The task only designs agent approval, capability, tool-call, or effect controls within one pinned
+  version; use `agent-execution-control-review`.
+- The task only designs eval datasets, graders, trajectory scoring, or oracle quality; use
+  `agent-eval-integrity-review`.
+- The task only manages prompt wording or output contracts; use `prompt-contract-quality-review`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Bundle manifest: bundle ID and digest; model identifier and settings; fully rendered prompt and
+  examples; tool schema, adapter, and backend contract versions; policy version; retrieval, memory,
+  embedding, index, and chunking versions; runtime and library lock; eval dataset and evaluator
+  versions; build provenance; creation time; and compatibility requirements.
+- Channel ledger: candidate, stable, rollback target, immutable bundle references, assignment rule,
+  assignment reason, sticky cohort key, exposure percentage or bounded population, and promotion
+  history.
+- Rollout ledger: static checks, offline replay, shadow, canary, staged expansion, observation
+  window, hard safety gates, quality and cost gates, control comparison, owner, and stop criteria.
+- Effect ledger: read, draft, write, send, delete, spend, credential, memory-write, compensation,
+  idempotency, unknown outcome, and whether shadow execution can suppress each effect.
+- Rollback ledger: pointer reversal, in-flight safe point, compatibility window, capability
+  revocation, pending effect reconciliation, compensation owner, and schema or data downgrade rule.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Pin current source, bundle inputs, provider or framework contracts, and baseline metrics before
+  comparing a candidate.
+- Treat model aliases, remote prompts, mutable tool schemas, external policy, retrieval indexes, and
+  evaluator defaults as moving dependencies until resolved to immutable identities.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize live
+  rollout, traffic movement, model calls, production writes, or release publication.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine bundle manifests, immutable identifiers, channel records, assignment rules, rollout
+  gates, shadow adapters, effect suppression, compatibility checks, rollback plans, revocation,
+  observability, focused tests, docs, route metadata, and synchronized templates.
+- Add an emergency safety overlay only when it can reduce capability, scope, budget, or exposure.
+- Do not let an emergency overlay add tools, widen permissions, increase budget, weaken approval,
+  lower validation, or promote a candidate.
+- Do not mutate the behavior bundle assigned to an in-flight run. Start a new run or use a declared
+  safe migration point with compatibility and effect reconciliation.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define one behavior bundle. Include every input that can change agent decisions, tool calls,
+   retrieved evidence, side effects, evaluation, or runtime semantics. Hash the canonical manifest
+   and preserve component digests rather than recording only a marketing version.
+2. Resolve mutable references. Pin the exact model snapshot when the provider supports it, rendered
+   prompt, examples, tool schema, adapter and backend contract, policy, index, embedding model,
+   memory schema, runtime lock, evaluator, and eval dataset used by the run.
+3. Keep candidate creation separate from stable promotion. Automation may build and register a
+   candidate, but it must not move the stable pointer until the declared gates succeed.
+4. Build a dependency and compatibility matrix. Name every automation and cohort that consumes the
+   changed component, plus tool, state, memory, event, prompt, and output schema compatibility.
+5. Run static and offline gates first. Validate manifest completeness, signatures or provenance,
+   schema compatibility, policy monotonicity, deterministic fixtures, regression replay, and
+   adversarial cases before online exposure.
+6. Shadow without external authority. Let the candidate observe representative inputs, but remove
+   write, send, delete, spend, credential, production-memory-write, and other committing tools.
+   Compare proposed actions and final state predictions without pretending suppressed effects prove
+   real-world success.
+7. Select canaries by stable work-unit identity, not a fresh random choice per request. Keep one
+   task, conversation, workflow, or account on one bundle unless a declared safe transition changes
+   it. Cover high-risk and representative cohorts without exposing only easy traffic.
+8. Observe at least one complete business work unit. Choose duration from task lifetime, delayed
+   effects, traffic volume, and detection latency; do not copy a universal time or percentage.
+9. Gate safety before quality and cost. Stop on authorization bypass, duplicate or unknown effects,
+   privacy or secret exposure, invariant violation, unsafe action rate, inability to reconcile, or
+   rollback failure even when aggregate quality improves.
+10. Compare both absolute limits and a concurrent control. Shared provider or infrastructure
+    failures can move candidate and stable together, while a healthy control can still hide an
+    absolute SLO breach.
+11. Expand in stages only after evidence is attributable to the exact bundle. Preserve cohort,
+    sample size, task mix, risk mix, confidence limits, delayed outcomes, and excluded traffic.
+12. Roll back the complete behavior contract. Move the pointer, revoke candidate capabilities,
+    stop new assignments, reconcile in-flight UNKNOWN effects, preserve idempotency, compensate
+    when exact reversal is impossible, and keep old schema readers and tool adapters available for
+    the declared compatibility window.
+13. Keep the emergency path attenuation-only. Apply a separately versioned, audited restriction
+    that can disable tools, narrow scopes, reduce budgets, require stronger approval, or stop
+    traffic. Never use it as an untested feature channel.
+14. Route infrastructure traffic, probe, shutdown, container, migration, and generic deployment
+    details to `deployment-rollout-safety-review`; route eval validity to
+    `agent-eval-integrity-review`; route tool authority and side-effect controls to
+    `agent-execution-control-review`.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every run is attributable to one immutable bundle and assignment decision.
+- Candidate creation cannot silently promote stable or rewrite in-flight behavior.
+- Shadow mode lacks committing capabilities, canaries are sticky and representative, and promotion
+  uses hard safety gates plus absolute and control-relative evidence.
+- Rollback covers capabilities, compatibility, in-flight effects, reconciliation, and compensation,
+  not only a routing pointer.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and `mustflow_check`.
+Do not infer live rollout, provider, production, traffic, model, or release commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a bundle component is mutable or unknown, stop attribution claims and record the unresolved
+  dependency.
+- If shadow execution can commit an effect, disable that capability before treating shadow evidence
+  as safe.
+- If candidate and control assignment is unstable, restart the comparison with a sticky cohort.
+- If rollback cannot reconcile in-flight effects or read old state, stop expansion and preserve the
+  last compatible bundle and evidence for the named owner.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Bundle identity and component manifest
+- Candidate, stable, assignment, and cohort decision
+- Offline, shadow, canary, staged-promotion, and hard-gate evidence
+- Compatibility, attribution, and delayed-outcome findings
+- Rollback, revocation, reconciliation, and compensation readiness
+- Command intents run and skipped checks
+- Remaining agent-release rollout risk