@massa-ai/cursor-plugin 1.6.0

package/skills/massa-ai/workflows/mobile-figma/mobile-figma-audit.md

@@ -0,0 +1,68 @@
+### Mobile Figma Audit
+
+Use this workflow for a findings-only audit of whether an existing Android Views XML, Android Jetpack Compose, iOS UIKit, iOS SwiftUI, KMP Compose Multiplatform, or mixed KMP/native implementation matches a specific Figma design. It compares Figma MCP evidence with a concrete feature, file set, screen, class/composable/view, commit range, branch comparison, or modified-file target.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Do not edit code. Route direct design implementation to `design`. Do not use this workflow for Flutter, React Native, web styling, generic Figma exploration, or MCP troubleshooting.
+
+1. Resolve/reuse `workflowSessionId`: `mobile-figma-audit-[entity]`.
+2. Load shared references:
+   - `references/mobile-figma-matcher/repository-detection.md` before platform guidance.
+   - `references/mobile-figma-matcher/core.md` for Figma, assets, mapping, comparison, Maestro, and claim contracts.
+   - `references/mobile-context.md` for mobile boundaries, parity, and verification context.
+   - `references/audit-scope.md` for target resolution and freshness.
+   - `references/audit-report-io.md` before producing the report.
+   - `references/codebase-investigation.md` for unfamiliar source.
+   - `references/context-firewall.md` before large Figma payloads, screenshots, hierarchy dumps, logs, or reports.
+   - `references/synapse-policy.md` when repeated massa-ai searches are expected.
+3. `recall` -> load current component/design-system conventions, accepted Figma deviations, prior mappings, source-set boundaries, accessibility constraints, asset pipelines, and project render recipes. Apply the audit Memory Freshness Gate; memory is not proof.
+4. Require both inputs before analysis:
+   - Figma source: URL/node ID or an explicit desktop selection accessible through Figma MCP.
+   - Concrete implementation target: feature/flow, files/globs, screen name, classes/composables, commits/range, branch comparison, or modified files.
+   - Ask for the missing input rather than guessing or defaulting to the whole app.
+5. Resolve one immutable audit scope packet and Target Surface Packet before Figma extraction or detailed source analysis. Classify every selected target module/source set and load only applicable contracts: Android Views, Android Compose, UIKit, SwiftUI, and/or KMP Compose Multiplatform. Mixed KMP targets load native contracts only for actual native hosts, wrappers, source sets, or requested runtime targets.
+6. Verify Figma MCP and build the Figma Evidence Packet from `references/mobile-figma-matcher/core.md` using `get_metadata` when needed, `get_design_context`, `get_screenshot`, `get_variable_defs`, and current Code Connect mappings when available. Stop if the node cannot be read; do not substitute a screenshot-only design contract.
+7. Establish one Platform Comparison Configuration per selected runtime surface. Record the fields required by that stack contract. Never compare Figma pixels directly with Android `dp`/`sp`, UIKit/SwiftUI points, or rendered pixels without the recorded density/display scale and text scaling.
+8. Extract a numbered design checklist covering only visible/in-scope elements and required states:
+   - Structure and ordering.
+   - Geometry, constraints, alignment, spacing, sizing, and insets.
+   - Typography, text content/wrapping, colors, opacity, shapes, borders, elevation/shadows, assets, and clipping.
+   - Interactive/semantic states represented by the design or target implementation.
+   - Adaptive, locale, font-scale, dark-mode, and accessibility constraints when relevant.
+9. Resolve implementation values to final values and record resource/token/asset chains. Verify existing components by source, semantics, states, and usage; never select a resource or variant because its name resembles a Figma token.
+10. For KMP, audit common composables/resources once, classify Android-only and iOS-native boundaries separately, and create distinct runtime rows for every requested platform target. Verify `expect`/`actual`, platform adapters, safe areas/insets, resource loading, and host integration when they affect the surface.
+11. Detect and run the strongest safe existing runtime sensors using the order in `references/mobile-figma-matcher/core.md`. Do not install screenshot tooling or rewrite baselines during audit.
+12. Detect Maestro MCP, Maestro CLI, device availability, and applicable existing flows independently:
+   - If MCP and a safe device are available, use non-destructive launch/navigation, hierarchy inspection, and screenshots for the target state.
+   - If CLI and an existing applicable flow are available, run it with an explicit artifact directory and compact report output.
+   - Prefer existing flows; do not create tracked Maestro flows during audit.
+   - If Maestro, device, or flows are unavailable, mark only those checks `NOT EVALUATED` and continue.
+13. Build the complete comparison matrix using required evidence classes and statuses. Every row carries a `Surface ID`. Try to disprove each mismatch through current source, resolved aliases, runtime configuration, platform constraints, source-set ownership, and design variants before reporting it.
+14. Create actionable findings only for confirmed `MISMATCH` rows:
+   - IDs: `MFM-<N>`.
+   - Severity: `critical` only for unusable/release-blocking target states; `high` for major structural or interaction mismatch; `medium` for clear visible component/layout mismatch; `low` for localized visual drift.
+   - Required fields: surface ID, UI stack, source set/module, element/state, property/constraint, Figma value, resolved implementation value, runtime evidence, evidence class, platform configuration, file/line, impact, smallest fix direction, and verification suggestion.
+   - Preserve justified deviations and unmeasured rows separately; do not convert them into false findings.
+15. Save or propose `audits/mobile-figma/<YYYY-MM-DD mobile-figma-audit>.md` using the report contract in `references/audit-report-io.md`. Include repository classification, Target Surface Matrix, Figma packet/mappings, per-surface configurations, capability matrix, comparison matrix, findings, justified deviations, not-evaluated rows, scope/evidence, and execution handoff.
+   - Include the Verification/Test Fidelity Checklist from `references/audit-report-io.md` as the proof layer over the comparison/capability matrices. Tie every `MFM-*` finding or no-finding claim to deterministic sensors, commands/artifacts, results, validation assets, or skipped-check reasons. Model judgment alone cannot satisfy verification/testing all-clear.
+16. Persist only durable token/component mappings, source-set ownership rules, approved accessibility/platform deviations, asset-pipeline rules, or reusable render recipes after Importance Calibration. Use `workflow:mobile-figma-audit` and required tags. Never persist screenshots, hierarchy dumps, raw logs, device IDs, or user data.
+17. Complete `references/evidence-gate.md`. A model visual impression cannot satisfy the gate.
+
+## Examples
+
+User asks: "Compare the LoginScreen Compose preview and modified files against this Figma node."
+
+1. Resolve the node, modified files, `LoginScreen`, theme/tokens, previews, and screenshot-test capability.
+2. Run existing preview/runtime sensors and optional Maestro evidence when available.
+3. Save a matrix-backed audit report with only confirmed mismatches as `MFM-*` findings.
+
+User asks: "Audit `res/layout/checkout.xml` against my current Figma selection."
+
+1. Resolve the desktop selection, XML layout, included resources, styles, drawables, and target device configuration.
+2. Use an existing XML/runtime render sensor if available; otherwise limit the claim to static values and mark visual runtime rows `NOT EVALUATED`.
+
+User asks: "Audit the shared checkout screen in our KMP app on Android and iOS."
+
+1. Detect shared Compose Multiplatform UI plus any Android/iOS hosts and map each surface to the Figma frame.
+2. Audit common composables once, then capture separate Android and iOS runtime/configuration evidence. Load native contracts only where native code participates.

package/skills/massa-ai/workflows/mobile-figma/mobile-figma-fix.md

@@ -0,0 +1,74 @@
+### Mobile Figma Fix
+
+Use this workflow only to fix confirmed `MFM-*` findings from a saved mobile Figma audit report.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Before the first repository mutation, load `references/implementation-delivery.md` for worktree isolation, atomic commits, PR creation, CI watch, and the merge gate, and `references/code-annotation.md` for doc blocks, rationale comments, and test coverage on every created or updated unit. If two consecutive fix attempts fail on the same symptom, stop editing and load `references/root-cause-scripts.md`.
+
+Do not execute from chat summaries, screenshots alone, remembered findings, or an unsaved comparison table. The saved `audits/mobile-figma/<YYYY-MM-DD mobile-figma-audit>.md` report is the source of truth. Route fresh comparison work to `mobile-figma-audit`.
+
+1. Resolve/reuse `workflowSessionId`: `mobile-figma-fix-[entity]`.
+2. Load shared references:
+   - `references/mobile-figma-matcher/repository-detection.md` before platform guidance.
+   - `references/mobile-figma-matcher/core.md` for Figma, assets, mapping, Maestro, matrix, and claim contracts.
+   - `references/lessons.md` to load confirmed project lessons
+   - `references/mobile-context.md` for mobile boundary and verification guidance.
+   - `references/audit-report-io.md` before any source or validation-asset edit.
+   - `references/audit-scope.md` and `references/codebase-investigation.md` for freshness and current source.
+   - `references/verification-ladder.md` before edits.
+   - `references/context-firewall.md` before large design/runtime artifacts.
+3. `recall` -> load current design-system rules, accepted deviations, prior component mappings, source-set boundaries, accessibility constraints, asset-pipeline rules, and render recipes for the target.
+4. Select a report and target focus:
+   - Prefer an exact report path plus optional `MFM-*` IDs.
+   - For `latest` or omitted path, require a concrete target focus, then select only from `audits/mobile-figma/`.
+   - Stop if no report exists or metadata does not identify `Workflow: mobile-figma-audit`, project/session, target/focus/scope, source timestamp, repository classification, Target Surface Matrix, Figma source/node mappings/timestamp, per-surface platform configurations, capability matrix, and comparison matrix.
+   - Reject legacy Android-only reports without the Target Surface Matrix and `Surface ID` fields. Require a fresh audit; do not infer or migrate the missing schema.
+5. Validate report freshness before editing:
+   - Re-resolve the target files, rebuild the Target Surface Packet, and verify git scope/base/head when relevant.
+   - Stop and re-audit when current module/source-set classification no longer matches the report.
+   - Re-read the same Figma node/selection and verify its current identity, variants, values, and screenshot. Stop and re-audit if material design drift invalidates findings.
+   - Verify every platform configuration is reproducible or explicitly accept a documented substitute.
+   - Recheck every selected finding's surface ID, UI stack, source-set/module, source location, resolved token/resource/asset chain, evidence, and constraint rationale.
+   - Reject `NOT EVALUATED`, `CONSTRAINT DEVIATION`, unknown, stale, or low-confidence rows as executable findings unless the user explicitly changes scope after re-audit.
+6. Load only platform contracts named by the selected findings and current Target Surface Packet. Build a remediation matrix: finding -> surface -> element/state/property -> Figma value -> current implementation value -> shared/platform root change -> affected files -> validation assets -> runtime sensor -> optional Maestro packet -> order -> status.
+7. Size work with the Verification Ladder. Route broad design-system migrations, unclear accessibility/product conflicts, or cross-feature component redesign to `spec-driven` before editing.
+8. Apply the smallest root fix:
+   - Prefer existing shared components, theme tokens, resources, dimensions, typography, shapes, and state definitions before local overrides.
+   - Preserve stack-specific accessibility, minimum touch targets, localization, safe areas/insets, adaptive behavior, and native platform conventions.
+   - For KMP, apply shared root fixes before platform-local overrides when the cause is shared, then verify every affected platform target.
+   - Keep XML/Compose, UIKit/SwiftUI, and KMP/native interoperability explicit. Do not duplicate one visual rule across layers when an established shared source owns it.
+   - Do not weaken screenshot tests, previews, fixtures, assertions, test tags, resource IDs, content descriptions, or Maestro selectors to hide a mismatch.
+   - Modify tracked Maestro flows only when the selected finding explicitly identifies the flow as incorrect or missing and the user-approved scope includes that change.
+9. Verify after each coherent finding group:
+   - If verification found a reusable signal (`ac_gap`, `surviving_mutant`, `spec_precision_gap`, `spec_deviation`, `gate_fail`), record it via `references/lessons.md`:
+     `python3 skills/massa-ai/scripts/lessons.py --root . add --feature "<slug>" --signal "<signal>" --source "<ref>" --text "<one terse lesson>"`
+   - Apply the Mandatory Verification Fix Gate from `references/verification-ladder.md`: run the report's Verification Suggestion or an equivalent deterministic command/artifact check for each selected `MFM-*` finding or coherent group.
+   - A finding cannot be marked `fixed` when a target-relevant command, render sensor, comparison artifact, or Maestro reproduction exists but was not attempted; if verification cannot run, mark it `blocked`, `deferred`, or `skipped` with an allowed skipped-check reason.
+   - Re-resolve every affected comparison row, not only the previous mismatch.
+   - Run focused static checks and existing preview/screenshot/instrumentation sensors.
+   - Re-evaluate every affected surface, including surfaces changed indirectly by a shared KMP fix.
+   - When Maestro evidence was used in audit and remains available, reproduce each recorded device/configuration/content state and rerun the same flow or navigation steps; capture equivalent hierarchy and screenshots.
+   - If Maestro becomes unavailable, record the regression gap instead of claiming equivalent runtime verification.
+10. Rebuild the final comparison matrix using fresh Figma and per-surface implementation evidence. Completion requires zero unresolved selected mismatches; all newly `NOT EVALUATED` rows remain residual risk. A passing Maestro flow does not change an unmatched visual row to `MATCH`.
+11. Produce a closure matrix with `MFM-*` ID, surface ID, status (`fixed`, `deferred`, `blocked`, `skipped`), changed files, final Figma/implementation values, command/artifact, result, skipped reason or `none`, highest Verification Ladder level reached, validation assets protected, static evidence, per-platform render evidence, optional Maestro evidence, and residual risk.
+12. Persist only durable token mappings, source-set ownership rules, approved constraint deviations, component reuse rules, asset-pipeline rules, or reusable verification recipes after Importance Calibration. Use `workflow:mobile-figma-fix` and required tags.
+13. Complete `references/evidence-gate.md` and report the highest Verification Ladder level reached.
+
+## Examples
+
+User asks: "Fix MFM-1 and MFM-3 from the latest LoginScreen mobile Figma audit."
+
+1. Select the latest report matching LoginScreen and validate the Figma node, reported target surfaces, and both findings.
+2. Fix shared theme/component causes before screen-local overrides.
+3. Rebuild every affected matrix row and rerun the strongest existing runtime sensors.
+
+User asks: "Apply the checkout mobile Figma report and verify with Maestro."
+
+1. Verify the report used Maestro and that the same safe device/flow remains available.
+2. Apply confirmed fixes, rerun the recorded flow, capture equivalent hierarchy/screenshots, and keep visual parity conclusions separate from flow success.
+
+User asks: "Fix the shared KMP spacing finding and its iOS host mismatch."
+
+1. Re-detect the common Compose and iOS host surfaces, load KMP plus the matching UIKit or SwiftUI contract, and verify the report schema/freshness.
+2. Apply the shared fix first, then the host-specific fix only if the mismatch remains; rebuild Android/iOS rows affected by the shared change.

package/skills/massa-ai/workflows/onboarding.md

@@ -0,0 +1,23 @@
+### 🟢 Onboarding (New Project / First Session)
+
+Use this workflow for a first session, missing project context, or repo setup where the agent must resolve the project identity, establish usable memory/index state, and capture a high-level architecture overview before deeper work.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+1. Resolve `projectId` and `workflowSessionId` (`onboarding-[entity]`).
+2. `recall` -> check for existing project identity and knowledge.
+3. `list_projects` -> resolve the exact registered project ID and index
+   status before indexing.
+4. If indexed, call `project_map` for the first architecture overview. A usable index means status is `indexed`, `project_map` succeeds, file count is >0, and symbol/chunk coverage is nonzero for code-bearing repositories.
+5. If no usable index exists, call `index` with `projectPath` and
+   `projectId`, then poll with the discipline in `references/mcp-tools.md`.
+6. Full reindex is allowed only when index status is `error`, `project_map` is missing/empty after indexing, or a large tracked-file change touched >50 files or >10% of tracked files since the last index timestamp. Treat `reindex` as compatibility-sensitive; fall back to `index(forceReindex=true)` with the known project path when its adapter contract is unverified.
+7. Honor root `AGENTS.md` ignored paths during context loading; if a tool cannot
+   accept excludes, discard ignored-path results instead of loading them.
+8. Load `references/synapse-policy.md` when architecture mapping will require
+   repeated searches, then follow the shared retrieval order from
+   `references/codebase-investigation.md`.
+9. Call `bootstrap` with `projectId` and `projectPath` to generate seed memories automatically from git log, README, docs, manifests, and centrality. `bootstrap` is idempotent (re-run is a no-op unless `force: true`); with LLM off it degrades to rule-based minimal seeds. Treat bootstrap seed memories as leads to confirm against current source, not as authoritative. If `bootstrap` is unavailable, proceed with manual `remember` calls.
+10. Persist the architectural overview via `remember` as a scored
+    `decision` memory with `memory:semantic`.
+11. Complete the Evidence Gate from `references/evidence-gate.md`.

package/skills/massa-ai/workflows/refactor.md

@@ -0,0 +1,47 @@
+### 🔨 Refactor
+
+Use this workflow for behavior-preserving structural cleanup, simplification, decoupling, testability improvements, and code organization changes where the intended external behavior stays the same. Do not use it for broken behavior; route that to `workflows/debug.md`. Do not use it for broad boundary redesign, migration, or unclear architecture direction; route that to `workflows/architecture/architecture-audit.md` or `workflows/spec-driven.md`.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Before the first repository mutation, load `references/implementation-delivery.md` for worktree isolation, atomic commits, PR creation, CI watch, and the merge gate, and `references/code-annotation.md` for doc blocks, rationale comments, and test coverage on every created or updated unit. If two consecutive fix attempts fail on the same symptom, stop editing and load `references/root-cause-scripts.md`.
+
+1. Resolve/reuse `workflowSessionId`: `refactor-[entity]`
+2. `recall` → load architectural decisions and coupling patterns for the area
+3. Load shared references as needed:
+   - `references/codebase-investigation.md` before changing unfamiliar code
+   - `references/architecture-lenses.md` when the refactor is driven by coupling, seams, adapters, depth, leverage, or locality
+   - `references/architecture-deepening-lens.md` and its Interface Design Method when a refactor candidate has two or more viable interface shapes (Design It Twice before choosing)
+   - `references/mobile-context.md` when the refactor touches KMP, iOS, Android, native bridges, mobile lifecycle, offline sync, permissions, local persistence, or backend-mobile contracts
+   - `references/verification-ladder.md` before Quick/Standard/Spec-driven sizing or edits
+   - `references/context-firewall.md` when source inspection or tool output meets its threshold table (a single source/log/doc block >200 lines, >20 KB, or >50 search hits)
+   - `references/pr-task-fix.md` when the verification ladder trigger table applies
+   - `references/lessons.md` when `.specs/lessons.json` exists, to load confirmed project lessons before refactoring
+4. Size the refactor before editing:
+   - Use the exact Quick, Standard, and Spec-driven thresholds in `references/verification-ladder.md`.
+   - Route boundary redesign to `workflows/architecture/architecture-audit.md`; route Spec-driven threshold work to `workflows/spec-driven.md` or split into atomic tasks.
+   - For Standard refactors or Quick refactors over 3 files/200 LOC, load `references/pr-task-fix.md`, run its ADR/TDD input gate, decompose work into Small-first independently buildable PR groups, and keep Medium groups only when splitting would break build, tests, UI, or review coherence.
+5. Follow the shared retrieval order from `references/codebase-investigation.md`
+   to find related code and usages. Call `impact_analysis` with `project`, `projectPath`, and `scope` to assess the centrality-ranked blast radius of the structural change before editing. `impact_analysis` only counts as evidence when the index is fresh for the current repository path and commit/worktree state; fall back to `search`/`get_references` and record reduced retrieval confidence when the index is stale or unavailable. An empty diff returns an empty impact set (not an error).
+6. Establish current behavior before moving code: tests, exact manual command transcripts, static checks, or artifact inspection
+7. For mobile refactors, characterize current bridge/API/platform behavior before moving code:
+   - shared vs platform-specific boundary
+   - native bridge payload and compatibility expectations
+   - impacted and comparison platforms
+   - deterministic mobile sensors or skipped platform checks from `references/mobile-context.md`
+8. Focus on pragmatic refactoring:
+   - Identify over-abstracted code and propose Modular Monoliths
+   - Reduce "abstraction cost" to make code more AI-navigable
+   - Verify changes do not break existing behavior using the verification recipe
+9. Execute by PR group when `references/pr-task-fix.md` applies:
+   - Order non-breaking groups by Data, Domain, then Presentation/Navigation, mapping those labels to repository boundaries when needed.
+   - Validate each group with the characterization and verification recipe before committing.
+   - Invoke `workflows/commit.md` for each verified group; do not duplicate commit staging, message, audit-exclusion, or Jira-prefix rules in this workflow.
+   - When every group has a confirmed Jira key, follow the reference's optional stacked branch flow: ask whether to create stacked task branches, ask for the base branch and a branch pattern containing `<jira-task-key>` if accepted, create each next branch from the previous task branch, never push, and report branches and commits in push order.
+10. Include file-integrity checks when tests, specs, benchmarks, fixtures, or snapshots are validation assets. If verification found a reusable signal (`ac_gap`, `surviving_mutant`, `spec_precision_gap`, `spec_deviation`, `gate_fail`), record it via `references/lessons.md`:
+     `python3 skills/massa-ai/scripts/lessons.py --root . add --feature "<slug>" --signal "<signal>" --source "<ref>" --text "<one terse lesson>"`
+11. Use `references/agent-orchestration.md` only for isolated implementation slices or independent verification
+12. At completion, persist (run the scoring rubric from `references/decision-engine.md`):
+   - Refactored architectural decisions via `remember` as scored `decision` memories
+   - Identified and decoupled anti-patterns via `remember` as scored `pattern` memories
+13. Complete the Evidence Gate from `references/evidence-gate.md`

package/skills/massa-ai/workflows/refinement/furps-refinement.md

@@ -0,0 +1,81 @@
+### FURPS+ Refinement
+
+Use this workflow for findings-only refinement of a Product Requirements Document (PRD) and/or Architecture Decision Record (ADR) against the FURPS+ quality model, before implementation. It runs The Fool as an input-validation pre-pass, then fans out one sub-agent per FURPS+ dimension, and emits a structured refinement report with open questions, suggestions, insights, risks, and Definition-of-Ready coverage gaps.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Do not use this workflow to author a new PRD (use `to-prd` or `spec-driven` Specify), author an ADR (use `adr`), propose change (use `rfc`), audit implementation against requirements (use `requirements-audit`), or audit code/security/architecture. It refines the document itself; it does not edit code.
+
+This workflow is findings-only. Do not edit the PRD/ADR unless the user separately asks.
+
+1. Resolve/reuse `workflowSessionId`: `furps-refinement-[entity]`. Resolve `projectId` per the router. Budget `recall` (`limit <= 3`, `minImportance >= 0.7`, `types=["critical","decision","pattern"]`) for prior ADRs, accepted decisions, DoR, and refinement patterns.
+2. Load shared references:
+   - `references/furps/intake.md` before intake and sub-agent dispatch
+   - `references/furps/checklist.md` for the per-dimension check items
+   - `references/furps/report-contract.md` before writing the report
+   - `references/furps/analyst-role.md` and `skills/agents/furps-analyst/SKILL.md` before dispatching `massa-ai-furps-analyst`
+   - `references/agent-orchestration.md` and `references/context-firewall.md` before dispatch
+   - `references/audit-report-io.md` before writing the final report
+   - `references/synapse-policy.md` when repeated massa-ai searches are expected
+   - `references/evidence-gate.md` at completion
+3. Intake and packet build (main), per `references/furps/intake.md`:
+   - Detect source (file / text / Jira / Confluence). Ingest via Atlassian MCP capability discovery (read-only) or file/text fallback.
+   - Resolve DoR (explicit / Jira/Confluence / built-in fallback). If none, use the fallback and mark DoR-gaps accordingly.
+   - Apply the context-firewall; build the bounded document packet (sections/summaries, DoR, recalled facts).
+   - If the source is missing or ambiguous, ask once before proceeding.
+4. The Fool pre-validation (sub-agents, one per mode):
+   - Load `workflows/the-fool.md`. Treat the PRD/ADR as the challenged thesis (direct challenge; inherit `projectId`/`workflowSessionId`).
+   - Dispatch a read-only `massa-ai-plan-critic` sub-agent in `evidence_audit` mode with the document packet, DoR, and recalled facts.
+   - Then dispatch a `massa-ai-plan-critic` sub-agent in `pre_mortem` mode, passing the `evidence_audit` summary as input.
+   - Collect the compact validation: source-confidence gaps, unsourceable claims, and execution-phase failure assumptions.
+   - Gate: if `evidence_audit` surfaces critical gaps that block meaningful FURPS analysis, ask the user whether to proceed-with-caveats or pause for document completion. Otherwise attach the Fool summary to the FURPS packets.
+5. FURPS+ dimension analysis (sub-agents, one per dimension, parallel):
+   - Dispatch six `massa-ai-furps-analyst` sub-agents: F, U, R, P, S, X (X = FURPS+ Extensions).
+   - Each receives its `checklist.md` section, the bounded document packet, the DoR, and the Fool summary.
+   - Each returns per check-item status (`covered|partial|missing|unclear`), `FR-<letter>-<N>` findings, and contributions to Open Questions / Suggestions / Insights / Risks / DoR-gaps.
+   - Run in parallel; batch if a concurrency cap applies. Each gets its own ephemeral Synapse session only if it performs >=2 searches.
+6. Synthesis (main):
+   - Collect the six dimension analyses and the Fool summary.
+   - Deduplicate, cross-check, and reconcile cross-dimension concerns (e.g., error flows span F3+R2+U1; components span F2+S2).
+   - Build the DoR coverage gap list (criteria not satisfied by the document).
+   - Assemble the report per `references/furps/report-contract.md`; assign `FR-<letter>-<N>` IDs.
+   - Plan Mode save rule: in Plan Mode return the canonical path and full content; in Default mode write `audits/refinement/<YYYY-MM-DD furps-refinement>.md`.
+7. Persist only durable knowledge:
+   - Do not persist one-off findings.
+   - Persist reusable refinement patterns and durable decisions after scoring.
+   - Required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:furps-refinement`, `entity:<entity>`, and one `memory:<tier>` tag.
+8. Complete the Evidence Gate from `references/evidence-gate.md`. Report deterministic evidence, changed artifacts, memory outcome, and residual risk.
+
+## Graceful Degradation
+
+| Failure | Behavior |
+|---|---|
+| Atlassian MCP unavailable / no matching capability | Ask for file/text; continue |
+| massa-ai unavailable | Skip recall; use file reads; skip memory write and log it |
+| Sub-agent spawning unavailable | Run dimensions sequentially in the main agent; record the skipped-delegation reason |
+| DoR not supplied | Use the built-in fallback; mark DoR-gaps explicitly |
+| Document too large | context-firewall: section summaries plus pointers to sub-agents |
+| Concurrency cap on six FURPS agents | Batch dispatch; preserve order-independence |
+
+## Examples
+
+User asks: "Refine this PRD against FURPS before we start building."
+
+1. `workflowSessionId=furps-refinement-<entity>`.
+2. Ingest the PRD file; resolve DoR from a linked Confluence page via Atlassian MCP.
+3. Run The Fool (`evidence_audit` then `pre_mortem`); proceed (no critical blocker).
+4. Fan out six `massa-ai-furps-analyst` sub-agents (F, U, R, P, S, X) in parallel.
+5. Synthesize; write `audits/refinement/<date> furps-refinement.md`; summarize in chat.
+
+User asks: "Run a FURPS+ analysis on ADR-007."
+
+1. `workflowSessionId=furps-refinement-adr-007`.
+2. Ingest the ADR from `docs/adr/007-*.md`; no DoR supplied, so use the built-in fallback.
+3. Run The Fool; `evidence_audit` flags two unresolved claims, so ask the user whether to proceed with caveats.
+4. On proceed, fan out the six dimension sub-agents; synthesize and save the report.
+
+User asks: "Check DoR coverage for this Jira epic and its Confluence ADR."
+
+1. `workflowSessionId=furps-refinement-<epic>`.
+2. Ingest the Jira epic plus Confluence ADR via Atlassian MCP; resolve DoR from the project DoR Confluence page.
+3. Run The Fool; fan out FURPS dimensions; emphasize the Definition of Ready — Coverage Gaps section.

package/skills/massa-ai/workflows/requirements/requirements-audit.md

@@ -0,0 +1,114 @@
+### Requirements Audit
+
+Use this workflow for findings-only review of whether a concrete target matches stated requirements without out-of-scope drift. Accepted targets include modified files, explicit files/globs, commit ranges, branch comparisons, modules/packages, symbols/classes/functions, feature/runtime flows, explicitly requested whole-repo scope, or an implementation scope packet supplied by `workflows/implementation/implementation-audit.md`.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Do not use this workflow for generic correctness bugs, security findings, architecture findings, code quality findings, or test coverage findings. Route correctness bugs to `workflows/bugs/bugs-audit.md` and route the other categories to their dedicated workflows.
+
+This workflow is findings-only. Do not edit code unless the user separately asks for fixes.
+
+1. Resolve/reuse `workflowSessionId`: `requirements-[entity]`
+2. Load shared references:
+   - `references/codebase-investigation.md`
+   - `references/audit-scope.md`
+   - `references/audit-report-io.md` before writing the final direct audit report
+   - `references/context-firewall.md` before inspecting large diffs, specs, issue text, generated reports, or broad search output
+   - `references/synapse-policy.md` when repeated massa-ai searches are expected
+   - `references/agent-orchestration.md` only for large scopes, explicit parallel/subagent requests, PR subagent invocation, or independent verification of high-impact findings
+3. `recall` -> load prior product decisions, accepted requirements, ADRs, scope constraints, known regressions, project patterns, and accepted exceptions for the target area.
+   - Apply the Memory Freshness Gate from `references/audit-scope.md`; recalled exceptions are leads, not proof.
+4. Establish the investigation scope before proceeding:
+   - Modified files scope: use when the user says modified files, changed files, current changes, uncommitted changes, staged changes, or unstaged changes.
+   - Explicit files/globs scope: use when the user names files, directories, or globs.
+   - Commit range scope: use when the user provides commits/ranges or asks for commits made by me, my branch commits, or requirement drift introduced by branch commits.
+   - Branch comparison scope: use when the user names base/head branches, refs, or a branch diff.
+   - Codebase area scope: use when the user names a path, module, package, feature area, user journey, or glob.
+   - Symbol/class/function scope: use when the user names public classes, functions, APIs, handlers, or exported surfaces.
+   - Feature/flow scope: use when the user names a runtime flow, user journey, or feature area.
+   - Whole-repo scope: use only when the user explicitly asks for a whole-repo requirements audit.
+   - Implementation parent scope: use only when `workflows/implementation/implementation-audit.md` invokes this workflow with a concrete implementation scope packet.
+   - Requirements source scope: use provided prompt text, PR description, issue text, task file, spec, RFC, ADR, acceptance criteria, or README section as the expected behavior source.
+   - If the target focus is missing, vague, or too broad, ask for a concrete target from the supported scope types in `references/audit-scope.md`.
+   - If requirements source is missing after checking the prompt, PR description, task file, spec, issue text, and repo docs, ask for the requirements source before proceeding.
+   - Build the shared scope packet from `references/audit-scope.md` and carry it into the report.
+5. For modified files scope:
+   - Include staged and unstaged tracked files from the working tree.
+   - Include untracked non-generated source, test, fixture, schema, config, and docs files only when they can affect required behavior.
+   - Exclude deleted files unless their deletion can break required behavior, imports, exports, routing, migrations, config, tests, packaging, or documentation contracts.
+   - Exclude generated, dependency, build, log, cache, temporary, and secret paths per repo rules.
+   - Inspect diffs first, then only the surrounding code needed to compare implementation against requirements.
+6. For commit range scope:
+   - If the user supplied explicit commits or a revision range, use that exact range.
+   - If the user asked for commits made by me, resolve author identity from `git config user.email`; if empty, use `git config user.name`.
+   - For branch-relative commit scopes, resolve the branch base from the upstream merge-base first, then fall back in order to `origin/main`, `origin/master`, `main`, and `master`.
+   - If the user asked for commits made by me, review branch-unique commits authored by the resolved identity.
+   - If no explicit range, required author identity, or branch base can be resolved, ask the user for the missing value before proceeding.
+   - Inspect changed files and diffs from those commits, then requirements sources, callers, tests, config, schemas, and docs only as needed.
+7. For codebase area scope:
+   - Require a concrete path, module, package, feature area, or glob.
+   - If the target area is missing, ask for it before proceeding.
+   - Follow the shared retrieval order from `references/codebase-investigation.md` to find entry points, public API, tests, config, docs, and acceptance criteria.
+8. For explicit files/globs, branch comparison, symbol/class/function, feature/flow, or explicitly requested whole-repo scope:
+   - Resolve the target with `references/audit-scope.md` and record the resolution method, base/head when relevant, resolved files, exclusions, requirements source, and freshness timestamp.
+   - For symbol/class/function targets, inspect definitions, call paths, public contracts, tests, config, docs, and requirement links only as needed.
+   - For feature/flow targets, map expected behavior from the requirements source to implementation, tests, docs, and public contracts.
+   - If whole-repo scope is requested, map top-level requirement areas first and report skipped depth checks rather than implying exhaustive coverage.
+9. For implementation parent scope:
+   - Accept the exact scope packet and requirement source from `implementation-audit`.
+   - Do not broaden beyond resolved files, surrounding code, public contracts, tests, config, docs, and requirements needed to verify a claim.
+   - Return compact findings to the parent implementation audit; do not write broad project memories unless explicitly assigned.
+10. Investigation pass. Dispatch `audit-specialist` per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
+
+> **Dispatch: `massa-ai-audit-specialist`** (role: `audit-specialist`) — charter `skills/agents/audit-specialist/SKILL.md`
+> - trigger: large scope, explicit parallel/subagent request, PR subagent invocation, or independent verification of high-impact finding
+> - scope: the requirements audit target — files, contracts, specs, acceptance criteria
+> - permissions: read-only
+> - inputs: shared scope packet; `lens: requirements`; requirement source, recalled requirements decisions, accepted exceptions
+> - sensors: build requirement checklist from source; trace implementation vs spec; coverage gap, ambiguity, contradiction, implicit-need detection
+> - output: findings with requirement gap, location, evidence, severity, confidence, simplest fix direction, verification suggestion
+> - firewall: raw diffs/logs/search output summarized, not returned raw
+> - memory: suggest-only; main agent persists reusable requirements patterns
+
+    - Build a requirement checklist from the source: must-have behavior, non-goals, acceptance criteria, compatibility constraints, inputs, outputs, and user-visible promises.
+   - Compare implementation and tests against each checklist item.
+   - Prioritize missing requirements, contradicted requirements, out-of-scope behavior, changed public contracts, compatibility breaks, incomplete edge cases, and docs or tests that misrepresent delivered behavior.
+   - For each candidate finding, record the concrete claim, source evidence, affected requirement, impacted flow, provisional severity, and what would disprove it.
+11. False-positive pass:
+   - Try to disprove every candidate before reporting it.
+   - Check requirement wording, accepted scope changes, ADRs, feature flags, compatibility notes, tests, docs, call paths, and user-provided constraints.
+   - Drop candidates disproven by evidence, downgrade candidates with partial mitigation, and mark low-confidence findings explicitly.
+12. Severity rules (apply the countable threshold first, then the qualitative clause):
+   - `critical`: implementation violates a mandatory requirement in a way that blocks release, causes data loss, breaks auth/privacy, OR affects >10 files; otherwise use the qualitative clause below.
+   - `high`: missing or contradictory core requirement, significant out-of-scope behavior, public contract break, or major compatibility regression.
+   - `medium`: incomplete edge-case requirement, unclear acceptance gap, recoverable behavior mismatch (<=10 affected files), missing required docs/test coverage around a requirement, or scoped regression.
+   - `low`: minor requirement ambiguity, wording mismatch, low-impact out-of-scope behavior, incomplete evidence, or weakly supported concern.
+13. Final report:
+   - Findings first, ordered by severity: `critical`, `high`, `medium`, `low`.
+   - Each finding must use `REQ-<N>` and include the canonical fields from `references/audit-report-io.md`: severity, confidence, requirement source, requirement ID or quote, requirement gap type, file/line, evidence, impact, simplest fix direction, and verification suggestion.
+   - If no requirements findings are found, say that clearly and list scope checked, requirement source used, and skipped checks.
+   - Include ruled-out candidates when they were plausible enough to matter.
+   - Include scope checked, deterministic evidence or skipped-check notes, memory outcome, and residual risk.
+   - Include the Verification/Test Fidelity Checklist from `references/audit-report-io.md`; tie every `REQ-*` finding or no-finding claim to deterministic sensors, commands/artifacts, results, validation assets, or skipped-check reasons. Model judgment alone cannot satisfy verification/testing all-clear.
+   - For direct top-level invocation, use the Plan Mode save rule and canonical report contract from `references/audit-report-io.md` for `audits/requirements/<YYYY-MM-DD requirements-audit>.md`.
+   - For implementation audit child invocation, return compact findings to the parent unless the parent explicitly requests saved audit artifacts.
+14. Persist only durable knowledge:
+   - Do not persist one-off findings.
+   - Persist durable requirements decisions, accepted scope constraints, repeated requirement-drift patterns, or reusable verification recipes after scoring with the Importance Calibration System.
+   - Use required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:requirements-audit`, `entity:<entity>`, and one `memory:<tier>` tag.
+15. Complete the Evidence Gate from `references/evidence-gate.md`.
+
+## Examples
+
+User asks: "Check modified files against the task requirements."
+
+1. Use `workflowSessionId=requirements-modified-files`.
+2. Resolve requirements from the prompt, task file, issue, PR description, or provided spec.
+3. Scope to staged, unstaged, and relevant untracked files.
+4. Report missing requirements and out-of-scope drift by severity.
+
+User asks: "Audit this PR against its description."
+
+1. Use `workflowSessionId=requirements-pr`.
+2. Scope to the PR diff and use the PR description as the requirements source.
+3. Return compact findings to the parent implementation audit when invoked as a subagent.

package/skills/massa-ai/workflows/requirements/requirements-fix.md

@@ -0,0 +1,93 @@
+### Requirements Fix
+
+Use this workflow only to execute fixes from a requirements audit markdown report.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Before the first repository mutation, load `references/implementation-delivery.md` for worktree isolation, atomic commits, PR creation, CI watch, and the merge gate, and `references/code-annotation.md` for doc blocks, rationale comments, and test coverage on every created or updated unit. If two consecutive fix attempts fail on the same symptom, stop editing and load `references/root-cause-scripts.md`.
+
+Do not use this workflow for findings-only requirements review; route that to `workflows/requirements/requirements-audit.md`. Do not use it for broad feature design when acceptance criteria are missing; route that to `workflows/spec-driven.md`.
+
+1. Resolve/reuse `workflowSessionId`: `requirements-fix-[entity]`
+2. Load shared references:
+   - `references/audit-report-io.md` before any code change
+   - `references/lessons.md` to load confirmed project lessons
+   - `references/codebase-investigation.md` before changing unfamiliar requirement flows
+   - `references/verification-ladder.md` before non-trivial edits
+   - `references/context-firewall.md` before inspecting large specs, diffs, generated reports, or broad search output
+   - `references/agent-orchestration.md` only for large/high-risk findings, disjoint implementation slices, or independent verification
+3. `recall` -> load product decisions, accepted scope constraints, public contracts, compatibility rules, requirement interpretations, and verification recipes for the report target.
+4. Select the requirements audit report with execution focus:
+   - Establish the report selector, target focus, requirements source, and optional finding selector before selecting a report. Target focus can be a flow, feature, public contract, module, files/globs, branch comparison, commit range, symbol/class/function, or explicit whole-repo target.
+   - If the user gives a path, read that exact markdown file.
+   - If the user asks for "latest" or gives no path, require a concrete target focus first; do not run the latest requirements report against an unspecified target.
+   - Select the latest `audits/requirements/<YYYY-MM-DD requirements-audit>.md` only after target focus is known, using `references/audit-report-io.md`.
+   - Stop if no report exists; do not infer findings from conversation history.
+   - Validate the report with `references/audit-report-io.md`: workflow, `ProjectId`, `Target`, `Target Focus`, scope, git base/head, required fields, `REQ-` IDs, requirement source, resolved files or material scope evidence, and current file/line evidence. Stop on invalid, stale, target-drifted, or ambiguous reports before editing.
+5. Extract actionable findings:
+   - Keep findings with concrete `Requirement Source`, `Requirement ID or Quote`, `Requirement Gap Type`, `Location`, `Evidence`, `Impact`, `Simplest Fix Direction`, and `Verification Suggestion`.
+   - Ignore ruled-out candidates and no-finding sections.
+   - If the user supplied finding IDs, extract only those IDs after validating they exist and match the current target focus and requirements source.
+   - Rank by mandatory requirement severity, dependency order, user-visible impact, compatibility risk, and testability.
+6. Build a traceability matrix before editing:
+   - Requirement ID/source -> audit finding ID -> current implementation evidence -> desired behavior -> files likely affected -> tests/docs needed -> verification command.
+   - Mark each item as missing requirement, contradicted requirement, out-of-scope behavior, compatibility break, docs mismatch, or test/docs gap.
+7. Size each finding with `references/verification-ladder.md`:
+   - Quick: local behavior correction, docs wording fix, config default correction, or focused test alignment.
+   - Standard: multi-file behavior change, public API compatibility fix, UI/API contract update, or meaningful test impact; define verification recipe first.
+   - Spec-driven: ambiguous requirement, new feature beyond audited scope, contract redesign, migration, or stakeholder tradeoff; pause and route to `workflows/spec-driven.md` or ask for approval.
+8. Apply requirements fixing methods:
+   - Missing requirement: implement the smallest behavior that satisfies the source requirement and add direct acceptance coverage.
+   - Contradicted requirement: change behavior to match the source of truth, unless the report identifies a newer accepted decision.
+   - Out-of-scope behavior: remove or guard behavior that exceeds non-goals, while preserving existing supported contracts.
+   - Compatibility break: restore previous public contract or add a compatible bridge if the report requires compatibility.
+   - Docs/test mismatch: update docs or tests to reflect delivered behavior only when implementation already matches the requirement.
+9. Guard scope:
+   - Do not reinterpret requirements beyond the report and cited source.
+   - Preserve non-goals and explicit constraints.
+   - If a finding exposes a product decision gap, stop and ask rather than inventing policy.
+10. Use agent orchestration only when it improves signal. Dispatch per `references/agent-orchestration.md`:
+
+> **Dispatch: `massa-ai-builder`** (role: `builder`) — charter `skills/agents/builder/SKILL.md`
+> - trigger: large/high-risk finding, disjoint implementation slice, or explicit subagent request
+> - scope: one isolated requirements finding with a disjoint write set
+> - permissions: write (disjoint write set)
+> - inputs: the finding ID, requirement source, gap/contradiction/ambiguity, and simplest fix direction
+> - sensors: report's verification suggestion or equivalent deterministic command; requirements-trace check
+> - output: implementation summary, commands run, test counts, deviations
+> - firewall: raw diffs/logs summarized
+> - memory: suggest-only; main agent persists reusable requirements patterns
+
+> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
+> - trigger: independent verification of a high-risk requirements fix
+> - scope: the fixed finding's requirement alignment, test coverage, and report claim closure
+> - permissions: read-only
+> - inputs: the finding, the applied fix, the verification suggestion, and validation assets
+> - sensors: deterministic command (requirements-trace check, test coverage, doc/spec alignment) and report claim closure
+> - output: confirmed/disproven closure verdict with evidence
+> - firewall: raw test output/logs summarized
+> - memory: suggest-only; main agent persists reusable verification recipes
+   - Main agent owns report parsing, traceability matrix, memory writes, final synthesis, and Evidence Gate.
+11. Verify each completed finding:
+   - If verification found a reusable signal (`ac_gap`, `surviving_mutant`, `spec_precision_gap`, `spec_deviation`, `gate_fail`), record it via `references/lessons.md`:
+     `python3 skills/massa-ai/scripts/lessons.py --root . add --feature "<slug>" --signal "<signal>" --source "<ref>" --text "<one terse lesson>"`
+   - Apply the Mandatory Verification Fix Gate from `references/verification-ladder.md`: run the report's Verification Suggestion or an equivalent deterministic command/artifact check for each selected finding or coherent group.
+   - A finding cannot be marked `fixed` when a target-relevant command or artifact check exists but was not attempted; if verification cannot run, mark it `blocked`, `deferred`, or `skipped` with an allowed skipped-check reason.
+   - Run the report's verification suggestion when available.
+   - Run acceptance tests, targeted unit/integration tests, docs checks, type/build checks, or manual artifact inspection relevant to the requirement.
+   - Update the traceability matrix status in the final report summary.
+   - Record command/artifact, result, skipped reason or `none`, highest Verification Ladder level reached, validation assets protected, and residual risk.
+12. At completion, persist only durable knowledge:
+   - Accepted requirement interpretations, scope constraints, compatibility rules, or reusable acceptance-test recipes after scoring with the Importance Calibration System.
+   - Use required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:requirements-fix`, `entity:<entity>`, and one `memory:<tier>` tag.
+13. Complete the Evidence Gate from `references/evidence-gate.md`.
+
+## Examples
+
+User asks: "Use requirements-fix to fix latest audit for checkout flow."
+
+1. Confirm target focus is `checkout flow`, then read the latest matching `audits/requirements/* requirements-audit.md`.
+2. Validate metadata, target focus, freshness, required fields, requirement source, and current evidence before editing.
+3. Build a requirement traceability matrix.
+4. Fix mandatory gaps and contradictions before lower-severity docs/test issues.
+5. Verify against the cited requirement source.

package/skills/massa-ai/workflows/rfc.md

@@ -0,0 +1,55 @@
+### RFC (Request for Comments)
+
+Use this workflow when a significant technical, process, product, vendor, tool, or policy decision is still open and stakeholders need a structured proposal before committing to a direction. Route a finalized architecture decision to `workflows/adr.md`, settled implementation design to `workflows/tdd.md`, and broad requirements-through-delivery work to `workflows/spec-driven.md`.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+## Workflow
+
+1. Resolve or reuse `projectId` and `workflowSessionId=rfc-[entity]`.
+2. Establish evidence before asking questions:
+   - `recall` relevant constraints, existing architecture or process, related proposals, prior attempts, rejected options, stakeholder expectations, and verification patterns.
+   - Load `references/rfc/discovery-and-sizing.md`.
+   - Inspect current source, project instructions, existing RFC conventions, decision records, tickets, and supplied research. Current source and approved project artifacts override stale memory.
+   - When supplied Figma links, nodes, desktop selections, or screenshots materially affect mobile UI options, use `workflows/design.md` as optional child context for visual feasibility only; the RFC still owns option comparison and recommendation. Screenshots are context-only unless paired with structured Figma evidence.
+   - Load `references/synapse-policy.md` when two or more related searches are expected and `references/context-firewall.md` before broad or verbose source inspection.
+3. Confirm workflow fit, classify the RFC type, and assign the required impact label `HIGH`, `MEDIUM`, or `LOW` using the preserved criteria in the discovery reference.
+4. Gather every missing mandatory field interactively in the user's language:
+   - Use the provider-specific `AskQuestion` capability and the preserved question schema when available.
+   - Ask concise conversational questions when `AskQuestion` is unavailable.
+   - Require title, background, full RACI roles, impact, urgency or due date, assumptions with confidence and invalidation triggers, weighted decision criteria, at least two options, and a recommendation.
+   - Reuse supplied or discoverable facts; do not ask for information already present.
+5. Load `references/rfc/document-contract.md` and draft the RFC in the same language as the user's request.
+   - Preserve the 7 mandatory and 4 recommended sections, numeric criterion weights, honest option comparison, generated cost and effort estimates, status quo consideration, action items, and outcome placeholder.
+   - Tailor conditional concerns to technical/architecture, process/workflow, product/feature, vendor/tool, or policy/compliance proposals.
+   - Mark generated estimates as estimates and state their assumptions when exact project data is unavailable.
+6. Choose the artifact path from an explicit user path or established project convention. Otherwise default to `docs/rfc/<entity>.md`.
+   - If the target exists, update it only when the user explicitly requested an update; otherwise ask before overwriting.
+   - When file mutation is unavailable or the user requested plan-only output, present the complete draft and intended path without writing.
+7. Run the full configured Plan Challenge Gate. Preserve all required RFC fields while revising valid critical or high findings, especially one-sided options, unsupported claims, hidden assumptions, status quo bias, weak cost estimates, and criteria chosen to justify a predetermined conclusion.
+8. Load `references/rfc/quality-and-lifecycle.md`, validate every required behavior, and resolve blocking gaps. Keep unresolved facts explicit instead of silently removing mandatory fields.
+9. Save the proposal with status `NOT STARTED` or `IN PROGRESS`. Set `COMPLETE` and fill the Outcome section only when an explicit human decision or authoritative project record is available.
+10. Persist proposal state after recall, deduplication, and scoring:
+   - Pending or in-review proposal: scored `conversation` memory with `memory:working`.
+   - Explicitly decided outcome, durable rejected options, and accepted constraints: scored `decision` memory with `memory:semantic`.
+11. Offer the preserved follow-up actions for stakeholder review, a decision deadline or meeting, Jira/Linear linkage, a downstream TDD, and Confluence publication when relevant.
+12. Complete `references/evidence-gate.md` and report the artifact path, status, RFC type, impact, options compared, challenge revisions, unresolved fields, memory outcome, and residual risk.
+
+## Failure Handling
+
+- massa-ai unavailable: continue from current source and project documents; report skipped durable-memory synchronization.
+- Evidence insufficient: use `AskQuestion` or concise conversation questions; do not omit a required field without naming the gap.
+- Direction already settled: stop and route to ADR or TDD instead of disguising implementation documentation as an RFC.
+- Only one credible option exists: research or elicit another option and compare the status quo; do not produce a one-sided proposal.
+- Existing document conflicts with current evidence: surface the conflict and request resolution before replacing the authoritative statement.
+- Jira, Linear, or Confluence unavailable: keep the suggested next step, but do not claim publication or linkage occurred.
+
+## Example
+
+User asks: "Draft an RFC comparing self-hosted Kafka, Amazon MSK, and Confluent Cloud. Cost and vendor lock-in matter most."
+
+1. Recall related platform decisions and inspect current messaging usage, operational constraints, and existing RFC conventions.
+2. Classify a technical/vendor RFC and assign impact from affected systems and teams.
+3. Use `AskQuestion` for missing Driver, Approvers, Contributors, Informed parties, due date, assumptions, and criterion weights.
+4. Compare all named options plus the status quo, generate transparent estimates, run the full challenge, and save the document under the project RFC convention.
+5. Persist the pending proposal as working memory and offer review, Jira/Linear, TDD, and Confluence follow-ups.