bmad-plus 0.12.2 → 0.14.0

package/src/bmad-plus/packs/pack-dev-studio/categories/analysis/domain-research.md

@@ -1,96 +1,58 @@
----
+---
 name: bmad-domain-research
-description: 'Conduct domain and industry research. Use when the user says wants to do domain research for a topic or industry'
+description: Map a domain's actors, operating processes, vocabulary and evidence-backed constraints.
 ---
 
-# Domain Research Workflow
-
-**Goal:** Conduct comprehensive domain/industry research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
-
-**Your Role:** You are a domain research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
-
-## Conventions
-
-- Bare paths (e.g. `domain-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.
-
-## PREREQUISITE
-
-**⛔ Web search required.** If unavailable, abort and tell the user.
-
-## 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.
-
-## QUICK TOPIC DISCOVERY
-
-"Welcome {{user_name}}! Let's get started with your **domain/industry research**.
-
-**What domain, industry, or sector do you want to research?**
-
-For example:
-- 'The healthcare technology industry'
-- 'Sustainable packaging regulations in Europe'
-- 'Construction and building materials sector'
-- 'Or any other domain you have in mind...'"
-
-### Topic Clarification
-
-Based on the user's topic, briefly clarify:
-1. **Core Domain**: "What specific aspect of [domain] are you most interested in?"
-2. **Research Goals**: "What do you hope to achieve with this research?"
-3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
-
-## ROUTE TO DOMAIN RESEARCH STEPS
-
-After gathering the topic and goals:
-
-1. Set `research_type = "domain"`
-2. Set `research_topic = [discovered topic from discussion]`
-3. Set `research_goals = [discovered goals from discussion]`
-4. Derive `research_topic_slug` from `{{research_topic}}`: lowercase, trim, replace whitespace with `-`, strip path separators (`/`, `\`), `..`, and any character that is not alphanumeric, `-`, or `_`. Collapse repeated `-` and strip leading/trailing `-`. If the result is empty, use `untitled`.
-5. Create the starter output file: `{planning_artifacts}/research/domain-{{research_topic_slug}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
-6. Load: `./domain-steps/step-01-init.md` with topic context
-
-**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for domain research.
-
-**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
+# Domain research
+
+Load the [execution guide](../../shared/execution.md) and
+[Miriam](analyst-agent.md). Explain the domain well enough to identify product
+constraints and questions requiring a domain expert.
+
+## Inputs
+
+Use the domain or industry, product decision, geographic scope, relevant users
+and time horizon. Identify any supplied procedures, policies or terminology.
+For regulated topics, establish the applicable jurisdiction and kind of entity
+before describing an obligation.
+
+## Procedure
+
+1. Bound the research to the decision. List the actors, activities and exchanges
+   the proposed product touches, together with important exclusions.
+2. Build a small vocabulary from original domain sources and supplied material.
+   Resolve terms with different meanings across organizations; keep ambiguity
+   visible rather than choosing a definition without evidence.
+3. Trace the normal operating process: trigger, actor, information required,
+   decision, output and exception. Identify handoffs, incentives and recurring
+   failure points. Distinguish documented practice from a suggested improvement.
+4. Research the constraints that could affect the product: authoritative rules,
+   technical standards, established operating practices and resource limits.
+   Use current official sources for legal or standards claims and record their
+   date, version, jurisdiction and applicability conditions.
+5. Separate binding obligations, nonbinding guidance and common practice. When
+   applicability is uncertain, record the uncertainty and the expert or source
+   needed to resolve it. Reading a rule is not a compliance assessment.
+6. Translate supported observations into product implications. Link each proposed
+   constraint to its evidence and identify dependencies that architecture or
+   planning must investigate.
+7. Summarize opportunities, tradeoffs and the most consequential unknowns.
+   Propose focused follow-up questions instead of a generic industry overview.
+
+## Output
+
+Produce a domain map, glossary, representative process, actors and incentives,
+constraints table, product implications and source ledger. The constraints table
+records the observation, evidence, applicability, proposed product consequence
+and unresolved question. Include decision scope and research/access dates.
+
+## Acceptance and continuation
+
+A reader must be able to trace a consequential product constraint to evidence
+and understand where specialist judgment is still needed. Do not claim legal,
+security or regulatory approval from a research document.
+
+Without current source access, complete the supplied-material analysis and label
+current obligations unverified. On resume, refresh changed rules and source
+versions, then revise the affected implications. Send supported requirements to
+[PRD creation](../planning/create-prd.md) when the user's task calls for planning.

package/src/bmad-plus/packs/pack-dev-studio/categories/analysis/market-research.md

@@ -1,96 +1,61 @@
----
+---
 name: bmad-market-research
-description: 'Conduct market research on competition and customers. Use when the user says they need market research'
+description: Research customer segments, alternatives and market assumptions for a specific product decision.
 ---
 
-# Market Research Workflow
-
-**Goal:** Conduct comprehensive market research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
-
-**Your Role:** You are a market research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
-
-## 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.
-
-## PREREQUISITE
-
-**⛔ Web search required.** If unavailable, abort and tell the user.
-
-## 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.
-
-## QUICK TOPIC DISCOVERY
-
-"Welcome {{user_name}}! Let's get started with your **market research**.
-
-**What topic, problem, or area do you want to research?**
-
-For example:
-- 'The electric vehicle market in Europe'
-- 'Plant-based food alternatives market'
-- 'Mobile payment solutions in Southeast Asia'
-- 'Or anything else you have in mind...'"
-
-### Topic Clarification
-
-Based on the user's topic, briefly clarify:
-1. **Core Topic**: "What exactly about [topic] are you most interested in?"
-2. **Research Goals**: "What do you hope to achieve with this research?"
-3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
-
-## ROUTE TO MARKET RESEARCH STEPS
-
-After gathering the topic and goals:
-
-1. Set `research_type = "market"`
-2. Set `research_topic = [discovered topic from discussion]`
-3. Set `research_goals = [discovered goals from discussion]`
-4. Derive `research_topic_slug` from `{{research_topic}}`: lowercase, trim, replace whitespace with `-`, strip path separators (`/`, `\`), `..`, and any character that is not alphanumeric, `-`, or `_`. Collapse repeated `-` and strip leading/trailing `-`. If the result is empty, use `untitled`.
-5. Create the starter output file: `{planning_artifacts}/research/market-{{research_topic_slug}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
-6. Load: `./steps/step-01-init.md` with topic context
-
-**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for market research.
-
-**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
+# Market research
+
+Load the [execution guide](../../shared/execution.md) and
+[Miriam](analyst-agent.md). Gather evidence that helps choose an audience,
+positioning or route to adoption.
+
+## Inputs
+
+Use the research question, product or opportunity, target geography, customer
+segment and decision horizon. Supplied interviews, sales data and source links
+may narrow the scope. Do not assume that a broad industry estimate describes
+the reachable customers for this product.
+
+## Procedure
+
+1. State the decision, scope and questions that could change it. Identify which
+   assumptions already have evidence and prioritize the uncertain ones.
+2. Choose relevant source types: official product pages and pricing, filings,
+   public statistics, original studies and supplied first-party observations.
+   Search current sources for claims about current conditions. Record publication
+   date or "undated", access date, geography and population where available.
+3. Compare customers' current alternatives, including manual processes or doing
+   nothing when relevant. Use consistent dimensions: job served, audience, entry
+   cost, constraints, distribution and switching effort. Distinguish vendor
+   claims from independent observations.
+4. Examine evidence for demand, buyer versus user differences, adoption barriers
+   and channels. Describe supplied interviews as their actual sample; a few
+   anecdotes do not establish population-wide demand.
+5. If size or economics matter, show the calculation, units, period, input
+   sources and sensitivity range. Separate total market, serviceable segment and
+   reachable opportunity. Do not manufacture unavailable inputs or imply more
+   precision than the evidence supports.
+6. Identify contradictions, missing segments and possible sampling bias. Prefer
+   an explicit unresolved question over an aggregate score built on missing data.
+7. Recommend a segment or positioning hypothesis, an alternative and the next
+   validation action. Tie the recommendation to sources and state what evidence
+   would reverse it.
+
+## Output
+
+Write a report with the decision and scope; customer segments and evidence;
+alternatives comparison; market or unit-economics estimate if justified;
+adoption opportunities and barriers; recommendation; open questions; and a
+source ledger. Each material claim links to a source or is labeled an assumption.
+Pricing comparisons include currency, billing basis, tier and observation date.
+
+## Acceptance and continuation
+
+The report must explain its coverage and limitations. If current web access is
+unavailable, analyze the supplied evidence and produce a dated partial report;
+do not present it as a completed current-market assessment.
+
+On resume, refresh time-sensitive claims and compare new evidence with the
+recorded assumptions. Recalculate estimates when an input changes. Feed
+supported findings into [Product brief](product-brief.md) without treating the
+research recommendation as authorization to change the product.

package/src/bmad-plus/packs/pack-dev-studio/categories/analysis/prfaq.md

@@ -1,135 +1,58 @@
----
+---
 name: bmad-prfaq
-description: Working Backwards PRFAQ challenge to forge product concepts. Use when the user requests to 'create a PRFAQ', 'work backwards', or 'run the PRFAQ challenge'.
+description: Explore a product concept through a proposed launch narrative and customer and delivery questions.
 ---
 
-# Working Backwards: The PRFAQ Challenge
-
-## Overview
-
-This skill forges product concepts through Amazon's Working Backwards methodology — the PRFAQ (Press Release / Frequently Asked Questions). Act as a relentless but constructive product coach who stress-tests every claim, challenges vague thinking, and refuses to let weak ideas pass unchallenged. The user walks in with an idea. They walk out with a battle-hardened concept — or the honest realization they need to go deeper. Both are wins.
-
-The PRFAQ forces customer-first clarity: write the press release announcing the finished product before building it. If you can't write a compelling press release, the product isn't ready. The customer FAQ validates the value proposition from the outside in. The internal FAQ addresses feasibility, risks, and hard trade-offs.
-
-**This is hardcore mode.** The coaching is direct, the questions are hard, and vague answers get challenged. But when users are stuck, offer concrete suggestions, reframings, and alternatives — tough love, not tough silence. The goal is to strengthen the concept, not to gatekeep it.
-
-**Args:** Accepts `--headless` / `-H` for autonomous first-draft generation from provided context.
-
-**Output:** A complete PRFAQ document + PRD distillate for downstream pipeline consumption.
-
-**Research-grounded.** All competitive, market, and feasibility claims in the output must be verified against current real-world data. Proactively research to fill knowledge gaps — the user deserves a PRFAQ informed by today's landscape, not yesterday's assumptions.
-
-## Conventions
-
-- Bare paths (e.g. `references/press-release.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.
-
-## 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}`. Be warm but efficient — dream builder energy.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Continue below.
-
-## Pre-workflow Setup
-
-1. **Resume detection:** Check if `{planning_artifacts}/prfaq-{project_name}.md` already exists. If it does, read only the first 20 lines to extract the frontmatter `stage` field and offer to resume from the next stage. Do not read the full document. If the user confirms, route directly to that stage's reference file.
-
-2. **Mode detection:**
-- `--headless` / `-H`: Produce complete first-draft PRFAQ from provided inputs without interaction. Validate the input schema only (customer, problem, stakes, solution concept present and non-vague) — do not read any referenced files or documents yourself. If required fields are missing or too vague, return an error with specific guidance on what's needed. Fan out artifact analyzer and web researcher subagents in parallel (see Contextual Gathering below) to process all referenced materials, then create the output document at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md` and route to `./references/press-release.md`.
-- Default: Full interactive coaching — the gauntlet.
-
-**Headless input schema:**
-- **Required:** customer (specific persona), problem (concrete), stakes (why it matters), solution (concept)
-- **Optional:** competitive context, technical constraints, team/org context, target market, existing research
-
-**Set the tone immediately.** This isn't a warm, exploratory greeting. Frame it as a challenge — the user is about to stress-test their thinking by writing the press release for a finished product before building anything. Convey that surviving this process means the concept is ready, and failing here saves wasted effort. Be direct and energizing.
-
-Then briefly ground the user on what a PRFAQ actually is — Amazon's Working Backwards method where you write the finished-product press release first, then answer the hardest customer and stakeholder questions. The point is forcing clarity before committing resources.
-
-Then proceed to Stage 1 below.
-
-## Stage 1: Ignition
-
-**Goal:** Get the raw concept on the table and immediately establish customer-first thinking. This stage ends when you have enough clarity on the customer, their problem, and the proposed solution to draft a press release headline.
-
-**Customer-first enforcement:**
-
-- If the user leads with a solution ("I want to build X"): redirect to the customer's problem. Don't let them skip the pain.
-- If the user leads with a technology ("I want to use AI/blockchain/etc"): challenge harder. Technology is a "how", not a "why" — push them to articulate the human problem. Strip away the buzzword and ask whether anyone still cares.
-- If the user leads with a customer problem: dig deeper into specifics — how they cope today, what they've tried, why it hasn't been solved.
-
-When the user gets stuck, offer concrete suggestions based on what they've shared so far. Draft a hypothesis for them to react to rather than repeating the question harder.
-
-**Concept type detection:** Early in the conversation, identify whether this is a commercial product, internal tool, open-source project, or community/nonprofit initiative. Store this as `{concept_type}` — it calibrates FAQ question generation in Stages 3 and 4. Non-commercial concepts don't have "unit economics" or "first 100 customers" — adapt the framing to stakeholder value, adoption paths, and sustainability instead.
-
-**Essentials to capture before progressing:**
-- Who is the customer/user? (specific persona, not "everyone")
-- What is their problem? (concrete and felt, not abstract)
-- Why does this matter to them? (stakes and consequences)
-- What's the initial concept for a solution? (even rough)
-
-**Fast-track:** If the user provides all four essentials in their opening message (or via structured input), acknowledge and confirm understanding, then move directly to document creation and Stage 2 without extended discovery.
-
-**Graceful redirect:** If after 2-3 exchanges the user can't articulate a customer or problem, don't force it — suggest the idea may need more exploration first and recommend they invoke the `bmad-brainstorming` skill to develop it further.
-
-**Contextual Gathering:** Once you understand the concept, gather external context before drafting begins.
-
-1. **Ask about inputs:** Ask the user whether they have existing documents, research, brainstorming, or other materials to inform the PRFAQ. Collect paths for subagent scanning — do not read user-provided files yourself; that's the Artifact Analyzer's job.
-2. **Fan out subagents in parallel:**
-   - **Artifact Analyzer** (`./agents/artifact-analyzer.md`) — Scans `{planning_artifacts}` and `{project_knowledge}` for relevant documents, plus any user-provided paths. Receives the product intent summary so it knows what's relevant.
-   - **Web Researcher** (`./agents/web-researcher.md`) — Searches for competitive landscape, market context, and current industry data relevant to the concept. Receives the product intent summary.
-3. **Graceful degradation:** If subagents are unavailable, scan the most relevant 1-2 documents inline and do targeted web searches directly. Never block the workflow.
-4. **Merge findings** with what the user shared. Surface anything surprising that enriches or challenges their assumptions before proceeding.
-
-**Create the output document** at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md`. Write the frontmatter (populate `inputs` with any source documents used) and any initial content captured during Ignition. This document is the working artifact — update it progressively through all stages.
-
-**Coaching Notes Capture:** Before moving on, append a `<!-- coaching-notes-stage-1 -->` block to the output document: concept type and rationale, initial assumptions challenged, why this direction over alternatives discussed, key subagent findings that shaped the concept framing, and any user context captured that doesn't fit the PRFAQ itself.
-
-**When you have enough to draft a press release headline**, route to `./references/press-release.md`.
-
-## Stages
-
-| # | Stage | Purpose | Location |
-|---|-------|---------|----------|
-| 1 | Ignition | Raw concept, enforce customer-first thinking | SKILL.md (above) |
-| 2 | The Press Release | Iterative drafting with hard coaching | `./references/press-release.md` |
-| 3 | Customer FAQ | Devil's advocate customer questions | `./references/customer-faq.md` |
-| 4 | Internal FAQ | Skeptical stakeholder questions | `./references/internal-faq.md` |
-| 5 | The Verdict | Synthesis, strength assessment, final output | `./references/verdict.md` |
+# PRFAQ
+
+Load the [execution guide](../../shared/execution.md) and
+[Miriam](analyst-agent.md). Test whether a product promise makes sense to a
+customer and can be supported by a plausible delivery plan.
+
+## Inputs
+
+Use the product idea or brief, intended audience, desired outcome, scope and
+known constraints. Read an existing PRFAQ before revising it. Identify which
+claims describe today's product and which describe a possible future release.
+
+## Procedure
+
+1. State the decision this exercise should inform. Extract the customer's task,
+   unmet need and current alternative from the supplied evidence.
+2. Write a short proposed launch narrative: headline, audience, problem, outcome,
+   how the first use works and availability assumptions. Label the narrative as
+   a proposal. Do not invent a real launch date, shipped feature, customer quote
+   or endorsement. Illustrative quotes, if useful, must be identified as such.
+3. Write the customer FAQ from a skeptical user's perspective: who benefits,
+   prerequisites, migration from the current approach, cost assumptions, data
+   handling, limits, failure recovery and how to stop using the product. Include
+   only topics relevant to the concept.
+4. Write the delivery FAQ: smallest useful release, dependencies, effort and cost
+   uncertainties, operational ownership, adoption obstacles and the strongest
+   reason the proposal might fail. Distinguish estimated answers from measured
+   evidence and record unresolved decisions.
+5. Challenge material promises against the evidence. Verify external pricing,
+   competitor behavior and feasibility claims using current primary sources
+   where possible. Unsupported claims remain hypotheses in the document.
+6. Revise the promise when the FAQs expose contradictions. Preserve unresolved
+   tradeoffs instead of giving every objection an invented answer. Define the
+   next observation or experiment that could accept or reject the concept.
+7. Distill the result into potential requirements and explicit exclusions. Keep
+   speculative features distinguishable from requirements supplied by the user.
+
+## Output
+
+Produce one report containing the proposed announcement, customer FAQ, delivery
+FAQ, claim-to-evidence table, candidate requirements, exclusions and next
+validation action. The claim table records the claim, its source or assumption,
+confidence limitation and consequence if false.
+
+## Acceptance and continuation
+
+The core promise, first-use description and delivery scope must agree. Readers
+must be able to distinguish proposed availability from an actual release.
+This artifact does not authorize publication or customer contact.
+
+On resume, compare changed claims and inputs, then revisit affected FAQ answers
+before editing the narrative. A supported concept can feed
+[Product brief](product-brief.md) or [PRD creation](../planning/create-prd.md).