bmad-plus 0.12.2 → 0.14.0

package/src/bmad-plus/packs/pack-dev-studio/categories/architecture/create-architecture.md

@@ -1,74 +1,70 @@
----
+---
 name: bmad-create-architecture
-description: 'Create architecture solution design decisions for AI agent consistency. Use when the user says "lets create architecture" or "create technical architecture" or "create a solution design"'
+description: Define an implementable architecture for an actual product or change request.
 ---
 
-# Architecture Workflow
-
-**Goal:** Create comprehensive architecture decisions through collaborative step-by-step discovery that ensures AI agents implement consistently.
-
-**Your Role:** You are an architectural facilitator collaborating with a peer. This is a partnership, not a client-vendor relationship. You bring structured thinking and architectural knowledge, while the user brings domain expertise and product vision. Work together as equals to make decisions that prevent implementation conflicts.
-
-## Conventions
-
-- Bare paths (e.g. `steps/step-01-init.md`) resolve from the skill root.
-- `this skill directory` resolves to this skill's installed directory (where `agent configuration` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Append-only document building through conversation
-- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `this skill file` — defaults
-2. `{project-root}/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/project config` and resolve:
-- Use `{user_name}` for greeting
-- Use `{communication_language}` for all communications
-- Use `{document_output_language}` for output documents
-- Use `{planning_artifacts}` for output location and artifact scanning
-- Use `{project_knowledge}` for additional context scanning
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Begin the workflow below.
-
-## Execution
-
-Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
-
-**Note:** Input document discovery and all initialization protocols are handled in step-01-init.md.
+# Create architecture
+
+Read the [execution guide](../../shared/execution.md) and
+[Bezalel's role](architect-agent.md). Use the
+[decision document guide](../../shared/architecture-decision-template.md) for the
+output. This page contains the complete procedure; no step-file runtime is needed.
+
+## Inputs
+
+A request or supplied artifact describing the desired behavior. For an existing
+project, inspect relevant code, manifests and prior decisions. A PRD, UX contract,
+load forecast or deployment constraint is evidence only if actually supplied or
+found and read. Record missing consequential facts as questions.
+
+## Procedure
+
+1. Establish the scope and baseline. Record the request, inspected input paths,
+   hashes when available, current implementation state and the decisions already
+   accepted. Identify what the architecture must enable and what is outside scope.
+2. Describe the significant journeys and constraints. Distinguish observable
+   behavior, invariants, service limits and design preferences. Connect each
+   consequential constraint to an input or an explicitly stated assumption.
+3. Examine the existing stack and operating environment. Locate extension points,
+   data stores, deployment configuration and project conventions. For a new
+   project, compare suitable foundations against actual needs; scaffolding or
+   changing dependencies is a separate action from selecting a design.
+4. Decide the consequential choices. For each, record the problem, credible
+   alternatives, chosen approach, costs, supporting evidence and a condition for
+   revisiting it. Resolve an essential unknown by inspection or a bounded,
+   authorized experiment; otherwise mark the affected decision provisional.
+5. Define component and data boundaries. Specify ownership, dependencies,
+   interface examples, validation, errors and state transitions. Cover access
+   control, sensitive data, concurrency, observability and recovery wherever the
+   system actually uses them. Avoid adding mechanisms without a requirement.
+6. Map the design onto the repository and delivery environment. Distinguish
+   existing paths from proposed paths, describe migrations and compatibility, and
+   identify the smallest useful implementation sequence with its dependencies.
+7. Walk through a representative success case, a relevant failure case and any
+   migration or restart that the change needs. Check each against the boundaries
+   and invariants. Record contradictions, missing decisions and the concrete
+   tests or measurements that would resolve them.
+8. Write the architecture report. Explain which parts are sufficiently specified
+   for implementation, which remain provisional, and the next bounded action.
+   Do not claim performance, security or deployment validation without evidence.
+
+## Output and acceptance
+
+Write the common report at the configured output path for create-architecture.
+Include context, input ledger, requirement-to-decision mapping, component/data
+boundaries, decision records, repository map, delivery sequence, verification
+plan and open risks. A diagram is useful only when its labels agree with the
+written interfaces.
+
+The report is complete when every in-scope consequential requirement has a
+decision or an explicit unresolved dependency, interface examples are consistent,
+and an implementer can identify the first slice and its acceptance checks.
+Record actual experiments separately from proposed tests. Provisional design
+can be delivered as a draft; it cannot be described as verified architecture.
+
+## Continue
+
+Read the existing report and compare its inputs with current files before editing.
+Keep user additions. Invalidate decisions whose assumptions or interfaces changed,
+then resume at the earliest affected procedure step. Preserve superseded decisions
+and the reason for replacement rather than silently rewriting project history.

package/src/bmad-plus/packs/pack-dev-studio/categories/architecture/create-epics-stories.md

@@ -1,93 +1,64 @@
----
+---
 name: bmad-create-epics-and-stories
-description: 'Break requirements into epics and user stories. Use when the user says "create the epics and stories list"'
+description: Turn requirements into traceable epics and implementable stories.
 ---
 
-# Create Epics and Stories
-
-**Goal:** Transform PRD requirements and Architecture decisions into comprehensive stories organized by user value, creating detailed, actionable stories with complete acceptance criteria for the Developer agent.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also a product strategist and technical specifications writer collaborating with a product owner. This is a partnership, not a client-vendor relationship. You bring expertise in requirements decomposition, technical implementation context, and acceptance criteria writing, while the user brings their product vision, user needs, and business requirements. Work together as equals.
-
-## Conventions
-
-- Bare paths (e.g. `steps/step-01-validate-prerequisites.md`) resolve from the skill root.
-- `this skill directory` resolves to this skill's installed directory (where `agent configuration` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step toward the overall goal is a self-contained instruction file; adhere to one file at a time, as directed
-- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- 🛑 **NEVER** load multiple step files simultaneously
-- 📖 **ALWAYS** read entire step file before execution
-- 🚫 **NEVER** skip steps or optimize the sequence
-- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `this skill file` — defaults
-2. `{project-root}/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/project config` and resolve:
-- Use `{user_name}` for greeting
-- Use `{communication_language}` for all communications
-- Use `{document_output_language}` for output documents
-- Use `{planning_artifacts}` for output location and artifact scanning
-- Use `{project_knowledge}` for additional context scanning
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Begin the workflow below.
-
-## Execution
-
-Read fully and follow: `./steps/step-01-validate-prerequisites.md` to begin the workflow.
+# Create epics and stories
+
+Read the [execution guide](../../shared/execution.md) and
+[Bezalel's role](architect-agent.md).
+
+## Inputs
+
+At least one explicit requirements artifact. Read any supplied architecture,
+UX decisions and existing backlog. Determine the intended outcome from their
+contents; file names alone do not establish requirements or readiness.
+
+## Procedure
+
+1. Inventory the requested outcomes and constraints. Preserve existing requirement,
+   epic and story identifiers. If inputs have no identifiers, assign local stable
+   IDs and record their source passages so later edits remain traceable.
+2. Inspect the existing backlog and implementation where available. Separate work
+   already evidenced from proposed work; do not infer completion from a title or
+   change a manually maintained status.
+3. Group related outcomes into epics with an observable benefit and a boundary.
+   Make stories small coherent increments that can be reviewed and tested.
+   Necessary infrastructure work should state the capability it enables and an
+   observable acceptance condition, rather than masquerading as a user journey.
+4. Define each story's intent, affected behavior, requirement references,
+   prerequisites, acceptance examples, exclusions and evidence needed to accept
+   it. Include failure or permission cases when they belong to the behavior.
+   Do not invent file paths before inspecting the relevant code.
+5. Order dependencies and check for cycles. Identify external prerequisites and
+   decisions that prevent a story from being actionable. Distinguish a useful
+   sequence from a hard dependency; avoid making independent stories wait without
+   a reason.
+6. Reconcile the set with the requirements. Find omitted constraints, duplicate
+   outcomes and acceptance criteria that cannot be observed. Revise the slices or
+   record the unresolved issue with the affected IDs.
+7. Deliver the backlog and recommend the first actionable slice. If capacity or
+   delivery dates are unknown, leave scheduling uncommitted rather than inventing
+   velocity or assigning people.
+
+## Output and acceptance
+
+Write the report for create-epics-stories with an epic overview, story records,
+dependency list and coverage table:
+
+| Requirement ID | Source | Story IDs | Acceptance evidence | Gap |
+| --- | --- | --- | --- | --- |
+| Use actual IDs | File and section | Existing or newly assigned IDs | Observable check | None or unresolved dependency |
+
+Each story record includes its stable ID, outcome, scope, dependencies and
+acceptance examples. Each in-scope requirement must map to a story or an explained
+deferral. A story is actionable only when its essential decisions and inputs are
+available. Report coverage gaps explicitly; a completed backlog is not completed
+implementation.
+
+## Continue
+
+Compare the current inputs and backlog with the saved input ledger. Preserve IDs,
+human status values and annotations. Add or revise affected stories, recording
+splits, merges and superseded IDs so existing references remain understandable.
+Recheck dependencies and coverage only for changes and their consequences.

package/src/bmad-plus/packs/pack-dev-studio/categories/architecture/generate-project-context.md

@@ -1,81 +1,59 @@
----
+---
 name: bmad-generate-project-context
-description: 'Create project-context.md with AI rules. Use when the user says "generate project context" or "create project context"'
+description: Capture concise project conventions and constraints from inspected sources.
 ---
 
-# Generate Project Context Workflow
-
-**Goal:** Create a concise, optimized `project-context.md` file containing critical rules, patterns, and guidelines that AI agents must follow when implementing code. This file focuses on unobvious details that LLMs need to be reminded of.
-
-**Your Role:** You are a technical facilitator working with a peer to capture the essential implementation rules that will ensure consistent, high-quality code generation across all AI agents working on the project.
-
-## Conventions
-
-- Bare paths (e.g. `steps/step-01-discover.md`) resolve from the skill root.
-- `this skill directory` resolves to this skill's installed directory (where `agent configuration` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Focus on lean, LLM-optimized content generation
-- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `this skill file` — defaults
-2. `{project-root}/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/project config` and resolve:
-- Use `{user_name}` for greeting
-- Use `{communication_language}` for all communications
-- Use `{document_output_language}` for output documents
-- Use `{planning_artifacts}` for output location and artifact scanning
-- Use `{project_knowledge}` for additional context scanning
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Begin the workflow below.
-
-## Paths
-
-- `output_file` = `{output_folder}/project-context.md`
-
-## Execution
-
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-Load and execute `./steps/step-01-discover.md` to begin the workflow.
-
-**Note:** Input document discovery and initialization protocols are handled in step-01-discover.md.
+# Generate project context
+
+Read the [execution guide](../../shared/execution.md) and
+[Bezalel's role](architect-agent.md).
+
+## Inputs
+
+A request naming what project or area to summarize, or an explicit project
+artifact. Inspect the selected directory with host tools; a prepared context
+bundle is not a repository inspection. Read current instructions and existing
+context before generating another file.
+
+## Procedure
+
+1. Identify the repository boundary and relevant source areas. Read project
+   instructions, manifests, build or test entry points and representative code.
+   Record the inspected revision or input hashes and any inaccessible areas.
+2. Extract facts that affect future work: runtime and package manager, directory
+   responsibilities, established extension patterns, actual verification commands
+   and deployment boundaries. Cite each consequential fact to its source.
+3. Capture invariants and recurring conventions using concrete examples. Separate
+   project requirements from an observed local pattern and from a recommendation.
+   Do not promote one unusual file into a universal rule.
+4. Check existing context and documentation for duplication or contradictions.
+   Resolve claims by inspecting the authoritative source; keep unresolved
+   disagreements visible. Summarize useful rules rather than copying large files
+   or storing sensitive values.
+5. Organize a compact context document around the decisions a future implementer
+   must make. Include where to look next and what has not been inspected. Label
+   commands as discovered or executed, with actual results only for executed
+   checks.
+6. Review each statement for evidence and ongoing relevance. Write the report,
+   or the user's requested project-context destination. Never overwrite generated
+   AGENTS.md or tool adapters; changes to their rules belong in their source
+   configuration and generation workflow.
+
+## Output and acceptance
+
+The report for generate-project-context contains scope and freshness, source
+ledger, project map, working conventions, acceptance/verification commands,
+invariants and unresolved questions. State the inspected area prominently when
+coverage is partial.
+
+A future assistant should be able to find the implementation area and the
+appropriate checks from this document. Unsupported prescriptions, duplicated
+manuals and hidden assumptions should be removed or labeled as proposals.
+The context is reference material and does not override project or user instructions.
+
+## Continue
+
+Read and preserve the existing document's human additions. Compare referenced
+sources and hashes, refresh affected facts and remove stale statements only with
+their replacement evidence recorded. An unchanged report date is not proof that
+the project stayed unchanged.

package/src/bmad-plus/packs/pack-dev-studio/categories/architecture/implementation-readiness.md

@@ -1,91 +1,58 @@
----
+---
 name: bmad-check-implementation-readiness
-description: 'Validate PRD, UX, Architecture and Epics specs are complete. Use when the user says "check implementation readiness".'
+description: Check whether a selected scope has enough consistent evidence to begin implementation.
 ---
 
-# Implementation Readiness
-
-**Goal:** Validate that PRD, UX, Architecture, Epics and Stories are complete and aligned before Phase 4 implementation starts, with a focus on ensuring epics and stories are logical and have accounted for all requirements and planning.
-
-**Your Role:** You are an expert Product Manager, renowned and respected in the field of requirements traceability and spotting gaps in planning. Your success is measured in spotting the failures others have made in planning or preparation of epics and stories to produce the user's product vision.
-
-## Conventions
-
-- Bare paths (e.g. `steps/step-01-document-discovery.md`) resolve from the skill root.
-- `this skill directory` resolves to this skill's installed directory (where `agent configuration` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## WORKFLOW ARCHITECTURE
-
-### Core Principles
-
-- **Micro-file Design**: Each step toward the overall goal is a self-contained instruction file; adhere to one file at a time, as directed
-- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- 🛑 **NEVER** load multiple step files simultaneously
-- 📖 **ALWAYS** read entire step file before execution
-- 🚫 **NEVER** skip steps or optimize the sequence
-- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `this skill file` — defaults
-2. `{project-root}/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/project config` and resolve:
-- Use `{user_name}` for greeting
-- Use `{communication_language}` for all communications
-- Use `{document_output_language}` for output documents
-- Use `{planning_artifacts}` for output location and artifact scanning
-- Use `{project_knowledge}` for additional context scanning
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Begin the workflow below.
-
-## Execution
-
-Read fully and follow: `./steps/step-01-document-discovery.md` to begin the workflow.
+# Implementation readiness
+
+Read the [execution guide](../../shared/execution.md) and
+[Bezalel's role](architect-agent.md).
+
+## Inputs
+
+At least one explicit planning or story artifact and the scope to assess. Use
+supplied requirements, architecture, UX, backlog and project constraints as
+applicable. A small maintenance task need not acquire unrelated planning documents.
+
+## Procedure
+
+1. Name the slice being assessed and inventory the artifacts actually read.
+   Record versions or hashes and whether each artifact describes the current
+   project. Separate absent documents from missing information.
+2. Extract the slice's intended behavior, acceptance criteria and invariants.
+   Check that essential terms, boundaries and failure behavior have a consistent
+   meaning across inputs. Cite conflicting passages precisely.
+3. Trace requirements through relevant UX or interface contracts, architecture
+   decisions and implementation tasks. Identify missing handoffs, contradictory
+   interfaces, uncovered constraints and acceptance checks with no observable
+   result.
+4. Inspect readiness dependencies: repository and runtime access, required data,
+   decision owners, migrations, credentials supplied through approved channels,
+   and test capabilities. Do not request or reproduce secret values in the report.
+   A promise that access exists is not a successful access check.
+5. Rank issues by their effect on the next implementation slice. Separate
+   prerequisites that stop it, decisions safely deferred, and improvements that
+   do not affect its acceptance. Give each blocking issue a source, consequence
+   and the smallest resolution action.
+6. Produce a disposition of ready, needs-resolution, or insufficient-evidence.
+   Ready requires the scoped prerequisites and acceptance path to be evidenced.
+   Missing information prevents a readiness claim for the affected scope;
+   unrelated missing documents do not block useful independent work.
+
+## Output and acceptance
+
+Write the report for implementation-readiness with assessed scope, input ledger,
+traceability table, issues, disposition and next actions. Use one row per relevant
+requirement or invariant with columns for source, implementing story or task,
+acceptance check and evidence status.
+
+Every blocking conclusion must cite a concrete contradiction or missing
+prerequisite. Zero issues is valid after completing the scoped assessment.
+Readiness means work can begin under the recorded assumptions; it does not mean
+the implementation is correct or that tests have passed.
+
+## Continue
+
+On new evidence, compare inputs and reassess only affected rows and dependencies.
+Keep prior issues and record their resolution evidence. A document revision or
+someone saying an issue is fixed is not itself proof of the relevant change.