mustflow 2.69.0 → 2.74.0

package/templates/default/locales/en/.mustflow/skills/adapter-boundary/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.adapter-boundary
 locale: en
 canonical: true
-revision: 12
+revision: 13
 lifecycle: mustflow-owned
 authority: procedure
 name: adapter-boundary
-description: Apply this skill when external systems, protocols, SDKs, databases, managed database features, authentication providers, webhooks, queues, files, object storage, public URL contracts, signed upload or download URLs, CDN transform rules, HTTP delivery transports, SSE, WebTransport, caches, API response models, framework requests or responses, server actions, route handlers, edge functions, worker handlers, AI models, AI gateway usage policy, AI provider cost and usage data, browser storage, search engines, analytics tools, email platforms, no-code tools, observability backends, trace or request context, or provider data cross into or out of core logic and need ports, adapters, translation, error mapping, timeout, retry, circuit-breaker, bulkhead, idempotency, security, cost attribution, reconciliation, core-state ownership, vendor portability, or observability boundaries.
+description: Apply this skill when external systems, protocols, SDKs, databases, managed database features, authentication providers, webhooks, queues, files, object storage, public URL contracts, signed upload or download URLs, CDN transform rules, HTTP delivery transports, SSE, WebTransport, caches, API response models, framework requests or responses, server actions, route handlers, edge functions, worker handlers, AI models, AI gateway usage policy, AI provider cost and usage data, browser storage, search engines, analytics tools, email platforms, no-code tools, observability backends, trace or request context, provider data, or a volatile component implementation cross into or out of core logic and need stable ports, adapters, translation, error mapping, timeout, retry, circuit-breaker, bulkhead, idempotency, security, cost attribution, reconciliation, core-state ownership, vendor portability, change isolation, or observability boundaries.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -33,6 +33,8 @@ Keep external-world language, protocols, failures, and operational concerns out
 
 This skill is not just a wrapper pattern. A good adapter boundary absorbs provider details, validates or maps untrusted input, classifies failures, applies timeouts and retry policy, preserves idempotency where needed, and records safe observability evidence without leaking secrets or personal data.
 
+Use the port as a change-isolation contract. Before changing the implementation behind the adapter, name which side is allowed to vary, which consumer contract must stay stable, and what evidence proves the opposite side did not have to change.
+
 <!-- mustflow-section: use-when -->
 ## Use When
 
@@ -49,6 +51,7 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
 - Provider SDK types, framework request or response objects, database rows, external event objects, raw model responses, or provider error types are visible in domain, application, service, or use-case code.
 - Delivery-layer tools such as server actions, route handlers, Web-standard handlers, edge middleware, CLI commands, cron handlers, workers, or admin actions are about to contain pricing rules, authorization policy, payment state transitions, entitlement decisions, external provider calls, or database transactions directly.
 - A new or changed port, repository, gateway, provider module, controller, worker, webhook handler, mapper, or integration test is needed.
+- A volatile component, provider, persistence detail, delivery surface, or algorithm should change behind a port without forcing callers, consumers, tests, public DTOs, stored data, or neighboring modules to change for the same reason.
 - The boundary needs timeout, retry, rate-limit, idempotency, signature verification, duplicate handling, logging, metrics, redaction, or provider-version decisions.
 - External calls can be slow, rate-limited, duplicated, partially completed, or ambiguous, and the system needs timeout, limited retry, backoff, circuit-breaker, queue isolation, dead-letter, or reconciliation behavior.
 - AI provider calls need a single internal boundary for model selection, prompt assembly, token usage, provider-call identity, request-to-call grouping, pricing snapshot, cache-hit classification, retry cost, plan limits, and redacted observability.
@@ -60,6 +63,7 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
 ## Do Not Use When
 
 - The change is a pure calculation, value object, internal formatter, or data-only refactor with no external boundary.
+- The task only needs broad ownership, cohesion, or future-change spread review before deciding whether a port is the right repair; use `module-boundary-review` or `change-blast-radius-review` first.
 - The only problem is hidden construction or global lookup of a dependency; use `dependency-injection` first, then return here only if external data, errors, or protocol behavior also need a boundary.
 - The operation coordinates several already-translated ports, repositories, queues, caches, or providers behind one caller-facing workflow; use `facade-pattern` for that high-level entry point while keeping this skill for each external boundary.
 - The task is a disposable one-off script that is not imported, repeated, tested, used in production, or connected to external systems.
@@ -69,6 +73,7 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
 ## Required Inputs
 
 - The external system or protocol and whether it is inbound, outbound, or both.
+- Change-isolation ledger: the volatile side, the stable consumer side, current callers, public contracts, compatibility constraints, and the smallest adapter-only change that should avoid caller edits.
 - The internal use case, domain action, or read model that should receive translated data.
 - Existing local patterns for ports, adapters, repositories, controllers, workers, mappers, result types, retries, idempotency, logging, and tests.
 - Provider-specific risk: write effects, duplicate delivery, unknown statuses, money, time, identifiers, secrets, personal data, files, untrusted URLs, rate limits, or provider version changes.
@@ -91,6 +96,7 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
 
 - Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
 - The boundary direction and owner are clear enough to avoid putting provider names or external protocol terms into core logic.
+- The preserved consumer contract is clear enough to test or report. If a caller-facing type, status, event, DTO, stored shape, or public behavior must change, classify that as a public-contract or migration change instead of hiding it inside an adapter refactor.
 - If the local layout is unfamiliar, use `pattern-scout` or `codebase-orientation` before introducing new folders or naming conventions.
 - If the change also introduces hidden collaborators or concrete construction, use `dependency-injection` for that part of the work.
 - If the change alters HTTP content coding, streaming flush behavior, SSE, WebTransport, WebSocket fallback, CDN/proxy behavior, or browser delivery compatibility, use `http-delivery-streaming` for the transport contract and keep this skill focused on core-boundary containment.
@@ -105,6 +111,7 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
 - Add mapper, error-mapper, fixture, fake-port, contract-test, and adapter-test files directly needed by the boundary.
 - Add or update assembly-root wiring when a new adapter implementation is introduced.
 - Do not copy provider APIs into ports, return provider SDK objects, expose database rows as domain objects, or add a broad catch-all `ExternalAdapter`.
+- Do not make callers change just because the adapter implementation, provider, storage shape, framework surface, or algorithm changed behind the port. If callers must change, name the missing contract or the intentional breaking change.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
@@ -112,12 +119,16 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
 1. Classify the boundary.
    - Inbound: HTTP route, controller, webhook, CLI command, queue consumer, scheduler, browser event, uploaded file, or external data import.
    - Outbound: provider SDK, HTTP API, database, cache, file storage, search engine, message publisher, email/SMS/push provider, payment provider, AI model, or browser storage.
+   - Change-isolation: a volatile component or implementation detail is expected to change behind a stable internal port while the consuming side should keep the same contract.
 2. Name the internal capability in business language. Use names such as `PaymentGateway`, `EmailSender`, `ObjectStorage`, `UserStore`, `OrderReader`, `SummaryGenerator`, or `EventPublisher`. Keep provider names such as Stripe, Prisma, SendGrid, S3, OpenAI, or Redis inside adapter implementation names.
    Treat external services as processors or presenters unless the architecture explicitly accepts them as a system of record. A payment provider can process money, an email tool can send messages, a search engine can rank derived documents, and an analytics tool can visualize events, but internal code should still own the facts needed to explain customers, rights, money, files, content, and important events.
 3. Design the port from the consumer's need, not from the provider's API.
    - Keep ports small and split unrelated reasons to change.
    - Use internal input and output types only.
    - Do not include SDK types, ORM model types, HTTP request objects, provider response objects, or provider error classes.
+   - Write down the preserved consumer contract before changing implementation code: accepted input, returned output, local error kinds, side effects, timing or ordering expectations, idempotency behavior, and observable public result.
+   - Make the adapter absorb representation changes. Provider response fields, table columns, wire envelopes, framework request objects, model output shapes, cache key syntax, or algorithm-specific options should change inside adapter or mapper files before consumer code sees them.
+   - If preserving the port would require lying about new behavior, stop and classify the change as a public API, migration, event, or workflow-contract change rather than stretching the adapter.
    - For survival-path providers, define the internal operation first, such as create checkout, grant entitlement, store file, send transactional email, enqueue job, or generate summary. Let adapter implementations translate that operation to Stripe, Supabase, S3, Resend, OpenAI, or another provider.
    - Do not build a fake "replace every vendor tomorrow" abstraction. Keep the boundary thin, but ensure provider names, dashboards, response shapes, and SDK errors do not become the language of the core use case.
    - Abstract product contracts, not every technology. Prefer boundaries such as user identity, permission checks, public URLs, file objects, entitlements, usage metering, AI generation, and billing rights over broad catch-all adapters that still leak provider concepts.
@@ -131,6 +142,7 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
    - For EventSource, SSE, WebTransport, WebSocket, and HTTP streaming adapters, translate protocol events into internal commands or read-model notifications. Keep event ids, reconnect tokens, datagram sequence numbers, fallback transport names, and proxy quirks out of core domain decisions unless they are explicitly product concepts.
 5. Build outbound adapters as provider translators, not pass-through wrappers.
    - Create provider requests from internal input.
+   - Keep adapter-only changes adapter-only. When a provider swap, storage rewrite, framework move, model routing change, or algorithm replacement forces caller edits, treat that as evidence the port mirrored the implementation instead of the consumer need.
    - Set timeouts and retry policy where appropriate.
    - Pass idempotency keys for writes when the provider supports them.
    - Use limited retries with backoff and jitter for transient failures. Do not retry malformed requests, denied authorization, or domain rejections.
@@ -199,6 +211,8 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
 13. Test at the right layer.
     - Use fake ports in use-case tests; they should not call real external systems.
     - Test adapters with provider fixtures, mock clients, or local test doubles for request mapping, response mapping, error mapping, timeout, retry, idempotency, redaction, and duplicate handling.
+    - Add or reuse preserved-consumer tests that prove callers use the port contract and do not import provider SDKs, framework request types, raw rows, adapter-only enums, or mapper internals.
+    - When the implementation behind the port changes, run or report tests that compare the old and new adapter behavior at the port boundary, not only tests that exercise the new provider happy path.
     - Add contract or sandbox tests for critical providers when local fixtures cannot catch provider drift.
 14. Verify with the narrowest configured command intents that cover changed source, tests, templates, docs, release metadata, and mustflow checks.
 
@@ -207,6 +221,7 @@ This skill is not just a wrapper pattern. A good adapter boundary absorbs provid
 
 - Core logic has no provider SDK imports, framework request or response objects, ORM clients, database rows, provider response objects, or provider error classes.
 - Ports are named in internal business language and expose only internal input, output, and error types.
+- Preserved consumer contracts are explicit, and implementation changes behind adapters do not force unrelated caller, DTO, test, workflow, or neighboring-module edits.
 - Provider dashboards, hosted settings, and SDK payloads do not become the only source for core business facts, search policy, queue failure policy, analytics event definitions, email customer state, or file ownership.
 - Public URLs, provider identity claims, image variants, entitlement decisions, and AI policy decisions are represented as product-owned contracts before provider-specific syntax reaches callers.
 - Streaming and delivery transport details such as SSE ids, WebTransport datagrams, content-coding variants, fallback paths, and CDN cache keys are contained at adapter boundaries before core logic receives product-level events or commands.
@@ -251,6 +266,7 @@ Prefer the narrowest configured test or build intent that proves the affected bo
 ## Output Format
 
 - Boundary classified
+- Change-isolation ledger and preserved consumer contract
 - Internal port or use-case input selected
 - Provider or protocol details contained
 - HTTP delivery, streaming, and fallback transport details contained when relevant
@@ -263,6 +279,7 @@ Prefer the narrowest configured test or build intent that proves the affected bo
 - Security and redaction surfaces checked
 - Observability identifier propagation and backend portability checked when relevant
 - Tests, fixtures, fakes, or contract checks added or reused
+- Evidence that implementation changes stayed behind the port, or the intentional breaking-change boundary
 - Command intents run
 - Skipped checks and reasons
 - Remaining boundary leakage or provider risk

package/templates/default/locales/en/.mustflow/skills/design-implementation-handoff/SKILL.md

@@ -0,0 +1,250 @@
+---
+mustflow_doc: skill.design-implementation-handoff
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: design-implementation-handoff
+description: Apply this skill when creating, reviewing, or using a two-agent design-to-implementation handoff where Agent A produces a specification and implementation plan, Agent B implements from that handoff, and private local planning files such as `.agent/MANIFEST.yaml`, `.agent/PLAN.yaml`, or `.agent/STATE.yaml` must be separated from public tracked product contracts. Use for local/private handoff setup, A-to-B implementation packages, ignored agent planning folders, startup gates, task state ledgers, and completion gates. Do not use for ordinary one-agent task prompts; use task-instruction-authoring instead.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.design-implementation-handoff
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Design Implementation Handoff
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Turn an Agent A design and an Agent B implementation request into a small, versioned handoff
+contract that preserves public product behavior while keeping private planning state out of the
+public repository when requested.
+
+This skill is for handoff structure, authority, ownership, and evidence. It is not a license to hide
+product behavior, invent missing requirements, or make ignored local files the only source of truth
+for a shipped system.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Agent A is asked to design, plan, specify, or break down work for Agent B to implement later.
+- Agent B is asked to implement from an existing design package, private planning folder, work plan,
+  or local-only agent handoff.
+- A repository needs a small design-to-implementation folder structure such as `spec/SPEC.md` plus
+  `.agent/MANIFEST.yaml`, `.agent/PLAN.yaml`, and `.agent/STATE.yaml`.
+- Private agent planning files should be ignored, excluded locally, backed up privately, or protected
+  from accidental staging.
+- The task needs a startup gate, version match, unresolved-question gate, task dependency gate,
+  allowed-path gate, blocker ledger, deviation ledger, or completion gate for another agent.
+- The design handoff may run locally with ignored files or remotely where ignored local files are not
+  automatically available.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only to write a normal coding-agent instruction, issue body, work order, or PR request;
+  use `task-instruction-authoring`.
+- The task is ordinary multi-worker coordination without a design package; use
+  `multi-agent-work-coordination`.
+- The task is only resuming incomplete work from a compact handoff; use `restricted-handoff-resume`.
+- The task asks to hide product behavior, security requirements, or acceptance criteria that should
+  remain reviewable with the code.
+- The user expects a cloud or remote agent to read local ignored files without an explicit attachment,
+  private remote, or prompt transfer path.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Target repository root and whether Agent B runs locally in the same workspace, in a cloud clone, or
+  in another environment.
+- Privacy mode: public product spec plus private plan, fully private local handoff, or private
+  external repository for handoff files.
+- Public behavior source: tracked `spec/SPEC.md`, existing docs, tests, schemas, or a user-supplied
+  alternative.
+- Private handoff paths, usually `.agent/MANIFEST.yaml`, `.agent/PLAN.yaml`, and `.agent/STATE.yaml`.
+- Agent A ownership, Agent B ownership, writable paths, read-only paths, allowed implementation
+  paths, forbidden paths, task dependencies, and verification expectations.
+- Ignore or exclude policy: shared `.gitignore`, local `.git/info/exclude`, or private repository for
+  `.agent`.
+- Completion evidence expected from Agent B: changed files, tests, verification runs, acceptance
+  mapping, blockers, deviations, and final verification.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Treat pasted advice, external examples, and AI-generated designs as reference input, not as current
+  repository authority.
+- Decide which facts must be tracked with the public code. Product behavior, acceptance criteria,
+  public contracts, migrations, and verification scripts usually belong in tracked files.
+- Decide which facts are private local planning state. Agent task order, temporary decisions,
+  progress ledgers, and local handoff state usually belong in `.agent`.
+- Do not create a hidden-only source of truth for behavior that future maintainers must preserve.
+- Do not assume ignored files are available to cloud agents, CI jobs, reviewers, or a fresh clone.
+- Do not run cleanup commands that can delete ignored handoff files.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Create or edit tracked public handoff surfaces such as `AGENTS.md`, `spec/SPEC.md`, verification
+  scripts, docs, tests, or templates when the user requests a durable repository setup.
+- Create or edit private local handoff files such as `.agent/MANIFEST.yaml`, `.agent/PLAN.yaml`, and
+  `.agent/STATE.yaml` when the current environment is allowed to hold private planning files.
+- Add shared ignore rules only when the team should know and share the private path policy.
+- Add local exclude or local hook guidance when the path should remain invisible to the public
+  repository.
+- Do not stage, commit, publish, summarize in public docs, or leak private handoff file contents
+  unless the user explicitly asks.
+- Do not modify `AGENTS.md`, ignore policy, public specs, or protected handoff paths while acting as
+  Agent B unless the handoff explicitly permits a design revision.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the handoff mode.
+   - Public spec and private plan: keep durable product behavior in tracked `spec/SPEC.md`; keep
+     task order and progress in `.agent`.
+   - Fully private local handoff: keep `AGENTS.md`, `SPEC.md`, plan, and state local; require a
+     separate private backup or private repository if the work matters.
+   - Remote Agent B: attach the private handoff, point B at a private accessible repository, or paste
+     the needed handoff into the task context; do not assume local ignored files cross the boundary.
+2. Create the smallest file set that can carry the contract.
+   - `AGENTS.md`: reusable implementation-agent rules only, not project feature plans.
+   - `spec/SPEC.md`: observable product behavior, non-goals, contracts, failure behavior,
+     concurrency, security, edge cases, acceptance criteria, and definition of done.
+   - `.agent/MANIFEST.yaml`: handoff status, spec version, plan version, read order, authority map,
+     ownership, protected paths, final verification, and completion rules.
+   - `.agent/PLAN.yaml`: Agent A-owned task list with dependencies, requirement IDs, acceptance IDs,
+     allowed paths, forbidden paths, deliverables, and verification requirements.
+   - `.agent/STATE.yaml`: Agent B-owned progress ledger with task states, changed files, tests,
+     verification runs, acceptance evidence, blockers, deviations, and final verification.
+3. Keep planning and progress separate.
+   - Do not put mutable status fields in `PLAN.yaml`.
+   - Do not let `STATE.yaml` override `SPEC.md` or `PLAN.yaml`.
+   - Allow only `pending`, `in_progress`, `blocked`, and `verified` task states unless the user
+     explicitly extends the state machine.
+4. Write the Agent B startup gate.
+   - Read `AGENTS.md`.
+   - Check whether the private manifest exists.
+   - Read every path in `read_order`.
+   - Confirm handoff status is `approved`.
+   - Confirm unresolved questions are empty.
+   - Confirm manifest, plan, and state versions match.
+   - Identify the first pending task whose dependencies are verified.
+   - Report that task's requirement IDs, acceptance IDs, allowed paths, forbidden paths, and
+     verification expectations before editing.
+5. Write the authority and ownership rules.
+   - `spec/SPEC.md` owns required product behavior.
+   - `.agent/PLAN.yaml` owns implementation order and task boundaries.
+   - `.agent/STATE.yaml` records evidence but does not change the design.
+   - Agent A owns spec, manifest, and plan.
+   - Agent B owns state, allowed production code, allowed tests, and allowed migrations for the
+     current task.
+6. Write the Agent B execution gate.
+   - Work on exactly one task.
+   - Do not start a task until all dependencies are `verified`.
+   - Mark the task `in_progress` before changing files.
+   - Stay inside the task's `allowed_paths`.
+   - Implement production code and tests together.
+   - Run the task's declared verification through the repository command contract when one exists.
+   - Record changed files, tests, verification results, and acceptance evidence.
+   - Mark the task `verified` only after required verification succeeds.
+7. Write the blocker and deviation rules.
+   - If `SPEC.md`, `MANIFEST.yaml`, `PLAN.yaml`, and current code conflict, do not guess.
+   - Record a blocker in `STATE.yaml` with requirement IDs, task ID, affected paths, and open
+     status.
+   - Record every design deviation with reason, impact, and approval status.
+   - Treat unapproved deviations as incomplete work.
+8. Choose the private-file protection mechanism.
+   - Use shared `.gitignore` only when every clone should ignore `.agent`.
+   - Use `.git/info/exclude` when the private path should remain a local-only convention with no
+     public trace.
+   - If `.agent` is important, recommend a separate private repository or private backup for that
+     folder; ignored files have no public repository history.
+   - Require evidence that `.agent` files are ignored or excluded and not tracked before completion.
+   - Warn that ignored files can still be force-added and can be deleted by cleanup commands that
+     remove ignored files.
+9. Add a completion gate.
+   - Every plan task is `verified`.
+   - Every acceptance criterion maps to source files and test files.
+   - The final verification command exits with the required status.
+   - No open blocker remains.
+   - No unapproved deviation remains.
+   - No private `.agent` file is tracked or staged in the public repository.
+10. Review the handoff for common failure modes.
+    - Hidden-only product behavior.
+    - Version numbers that do not change when Agent A revises the design.
+    - `allowed_paths` so broad that Agent B can rewrite the whole repository.
+    - Verification commands copied from external advice instead of mapped to the repository command
+      contract.
+    - Private local files expected by a remote agent.
+    - Progress state mixed into the immutable plan.
+    - Ignored files with no backup.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Public product behavior is separated from private agent planning state.
+- Agent A and Agent B ownership boundaries are explicit.
+- Agent B can identify the next executable task without inventing missing decisions.
+- Private handoff files are protected from accidental public tracking according to the selected
+  privacy mode.
+- The handoff names its remote-agent limitation when private local files are not automatically
+  transferred.
+- Completion requires task verification, acceptance traceability, blocker/deviation closure, and
+  private-file tracking checks.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `mustflow_check`
+
+When adding this handoff to a mustflow template or package surface, also use the relevant configured
+template, docs, package, or release checks.
+
+For downstream repositories, map any final verification command named in the handoff to that
+repository's command contract. If no configured command exists, record the verification as missing
+or manual instead of inventing a runnable command.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the user wants all design material hidden, warn that future maintainers and remote agents will
+  not see the design unless it is separately attached or privately stored.
+- If product behavior appears only in `.agent`, either move the public behavior contract to a
+  tracked spec or report the hidden-source-of-truth risk.
+- If Agent B cannot access `.agent`, downgrade the handoff to explicit user instructions or require
+  an attachment/private remote before implementation.
+- If ignore or exclude policy is unclear, choose no public ignore edit and report the local exclude
+  option rather than leaking private-path conventions into the repository.
+- If a private handoff file is already tracked, report that ignore rules do not untrack existing
+  files and require an explicit untracking or history-cleanup decision before claiming privacy.
+- If version numbers disagree, stop implementation and request or record an Agent A handoff refresh.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Handoff mode selected
+- Public tracked contract files
+- Private local handoff files
+- Agent A and Agent B ownership
+- Startup gate and next-task gate
+- Ignore or exclude protection decision
+- Remote-agent transfer limitation
+- Verification and completion gates
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining privacy, authority, or handoff risks

package/templates/default/locales/en/.mustflow/skills/routes.toml

@@ -640,7 +640,7 @@ applies_to_reasons = ["code_change", "security_change", "migration_change"]
 category = "data_external"
 route_type = "primary"
 priority = 55
-applies_to_reasons = ["code_change", "behavior_change"]
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "cross_cutting_code_change"]
 
 [routes."tauri-code-change"]
 category = "data_external"
@@ -924,6 +924,12 @@ route_type = "authoring"
 priority = 62
 applies_to_reasons = ["unknown_change", "docs_change", "workflow_change", "mustflow_docs_change"]
 
+[routes."design-implementation-handoff"]
+category = "workflow_contracts"
+route_type = "authoring"
+priority = 64
+applies_to_reasons = ["unknown_change", "docs_change", "workflow_change", "mustflow_docs_change"]
+
 [routes."project-context-authoring"]
 category = "workflow_contracts"
 route_type = "authoring"

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.69.0"
+version = "2.74.0"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -106,6 +106,7 @@ creates = [
   ".mustflow/skills/contract-sync-check/SKILL.md",
   ".mustflow/skills/cross-platform-filesystem-safety/SKILL.md",
   ".mustflow/skills/date-number-audit/SKILL.md",
+  ".mustflow/skills/design-implementation-handoff/SKILL.md",
   ".mustflow/skills/database-change-safety/SKILL.md",
   ".mustflow/skills/database-migration-change/SKILL.md",
   ".mustflow/skills/database-query-bottleneck-review/SKILL.md",
@@ -292,6 +293,7 @@ minimal = [
   "config-env-change",
   "contract-sync-check",
   "date-number-audit",
+  "design-implementation-handoff",
   "database-change-safety",
   "database-migration-change",
   "database-query-bottleneck-review",
@@ -424,6 +426,7 @@ patterns = [
   "config-env-change",
   "contract-sync-check",
   "date-number-audit",
+  "design-implementation-handoff",
   "database-change-safety",
   "database-migration-change",
   "database-query-bottleneck-review",
@@ -567,6 +570,7 @@ oss = [
   "contract-sync-check",
   "cross-platform-filesystem-safety",
   "date-number-audit",
+  "design-implementation-handoff",
   "database-change-safety",
   "database-migration-change",
   "database-query-bottleneck-review",
@@ -723,6 +727,7 @@ team = [
   "contract-sync-check",
   "cross-platform-filesystem-safety",
   "date-number-audit",
+  "design-implementation-handoff",
   "database-change-safety",
   "database-migration-change",
   "database-query-bottleneck-review",
@@ -864,6 +869,7 @@ product = [
   "config-env-change",
   "contract-sync-check",
   "date-number-audit",
+  "design-implementation-handoff",
   "database-change-safety",
   "database-migration-change",
   "database-query-bottleneck-review",
@@ -1014,6 +1020,7 @@ library = [
   "contract-sync-check",
   "cross-platform-filesystem-safety",
   "date-number-audit",
+  "design-implementation-handoff",
   "database-change-safety",
   "database-migration-change",
   "database-query-bottleneck-review",