sddflow 2.7.1__tar.gz → 2.7.2__tar.gz

{sddflow-2.7.1 → sddflow-2.7.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sddflow
-Version: 2.7.1
+Version: 2.7.2
 Summary: SDD Framework CLI — initialize and upgrade Spec-Driven Development packs
 Project-URL: Homepage, https://github.com/sunil1983us/universalguide
 Project-URL: Repository, https://github.com/sunil1983us/universalguide

{sddflow-2.7.1 → sddflow-2.7.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "sddflow"
-version = "2.7.1"
+version = "2.7.2"
 description = "SDD Framework CLI — initialize and upgrade Spec-Driven Development packs"
 readme = "README.md"
 requires-python = ">=3.9"

sddflow-2.7.2/sdd/__init__.py

@@ -0,0 +1 @@
+__version__ = "2.7.2"

{sddflow-2.7.1 → sddflow-2.7.2}/sdd/commands/upgrade.py

@@ -36,6 +36,20 @@ MIGRATIONS = [
         ],
         "migrate": lambda m: {**m, "sdd_version": "2.7.0"},
     },
+    {
+        "from":        "2.7.0",
+        "to":          "2.7.1",
+        "description": "Content release — no manifest schema changes",
+        "notes": [
+            "/create-context: Endpoints and NFRs now get a proposed "
+            "scope-appropriate starting default, marked "
+            "(SUGGESTED DEFAULT — edit or confirm), instead of always "
+            "falling back to [MISSING — ask user]",
+            "Re-copy the pack (or run sdd init over it) to pick up the "
+            "updated .github/prompts/create-context.prompt.md",
+        ],
+        "migrate": lambda m: {**m, "sdd_version": "2.7.1"},
+    },
 ]
 
 

{sddflow-2.7.1/sdd/packs/sdd-fullstack → sddflow-2.7.2/sdd/packs/sdd-backend-service}/.github/prompts/create-context.prompt.md

@@ -67,29 +67,59 @@ Map the raw input onto every section of context-template.md:
   10. Open Questions
   11. Tech Stack
 
-For each section:
-- Fill in anything the raw input states or clearly implies. Mark
-  agent-inferred content with "(inferred — confirm)".
-- If a section has nothing to go on, write `[MISSING — ask user]`.
-
-## Step 3 — Missing Information Checklist
-Produce a numbered, plain-language checklist — one question per
+For each section, fill it using the first tier below that applies:
+1. **Stated or clearly implied** — fill directly.
+2. **Agent-inferred** from something adjacent in the notes (e.g. an actor's
+   action in Key Flows implies an Endpoint, or a rule implies an NFR) —
+   fill it, mark "(inferred — confirm)".
+3. **Nothing stated or implied, but a safe generic starting point exists**
+   — applies ONLY to Endpoints and Non-Functional Requirements, never to
+   Actors, Business Rules, Constraints, Out of Scope, Open Questions, or
+   Tech Stack (those have no safe generic default — a wrong guess there
+   reads as a fabricated fact, not a placeholder number):
+   - **Endpoints**: derive one row per action verb found in Key Flows
+     (e.g. "submits X via API" → `POST /api/v1/{resource}`, "looks up Y"
+     → `GET /api/v1/{resource}`). If Key Flows gives nothing to derive
+     from either, propose one row per Actor named (a create + a read
+     endpoint is a reasonable starting shape for most services).
+   - **NFRs**: propose the same illustrative baseline this pack's own
+     templates use as examples, scaled to `manifest.project.scope`:
+     `pilot` → `P99 < 500ms`, `99% availability`, best-effort throughput;
+     `mvp`/`full` → `P99 < 300ms`, `99.9% availability`, `100 TPS peak`.
+   - Mark every row produced this way "(SUGGESTED DEFAULT — edit or
+     confirm)" — distinct from "(inferred — confirm)" so the user can
+     tell a guess grounded in their notes apart from a generic placeholder.
+4. **Nothing to go on and no safe default applies** — write
+   `[MISSING — ask user]`.
+
+## Step 3 — Review Checklist
+Split the open items into two groups so review effort goes where it's
+actually needed — don't make the user re-type things they'd only confirm:
+
+**Group A — Confirm or edit these starting defaults** (one line per
+`(SUGGESTED DEFAULT — edit or confirm)` marker). State the proposed value
+and invite a one-line override, e.g.:
+  1. (Endpoints) Proposed: `POST /api/v1/payments`, `GET
+     /api/v1/payments/{id}` — derived from your Key Flows. Keep these, or
+     tell me the real paths/verbs.
+  2. (NFRs) Proposed pilot-scope defaults: P99 < 500ms, 99% availability,
+     best-effort throughput. Keep these, or give me your real numbers.
+
+**Group B — Still need your input** (one question per
 `[MISSING — ask user]` marker, grouped by section, written for a
-non-technical reader. Examples:
+non-technical reader), for example:
   1. (Tech Stack) What programming language/framework will this use? If
      you're not sure, say "not sure — recommend one" and the architect can
      decide later at /plan-design.
   2. (Actors) Who are the different types of people or systems that will
      use this? (e.g. "customer", "admin", "support team", "another
      internal service")
-  3. (NFRs) Roughly how many users/requests per day? Any uptime
-     requirement (e.g. "must be up during business hours" vs "24/7")?
-  4. (Constraints) Any rules you must follow (legal, security, "must use
+  3. (Constraints) Any rules you must follow (legal, security, "must use
      our existing X system", budget/timeline)?
-  5. (Out of Scope) Anything people might assume is included but isn't,
+  4. (Out of Scope) Anything people might assume is included but isn't,
      for this first version?
 
-STOP here. Show the draft context.md AND the checklist.
+STOP here. Show the draft context.md AND both groups.
 
 ### Confluence Draft Option (if Confluence is configured)
 Check whether `.specify/integrations.yml` exists and has a `confluence:` section.
@@ -100,8 +130,10 @@ sdd confluence draft --doc context
 ```
 Then tell the user:
 > "I've pushed the draft to your Confluence space — open the link above.
-> Fill in the highlighted `[MISSING — ask user]` sections (you can share
-> the page with stakeholders directly in Confluence).
+> Review the highlighted `(SUGGESTED DEFAULT — edit or confirm)` rows
+> (Endpoints/NFRs — keep them or overwrite with your real numbers) and
+> fill in the `[MISSING — ask user]` sections (you can share the page
+> with stakeholders directly in Confluence).
 > When you're done editing, just say **'done'** here and I'll pull the
 > latest version automatically."
 
@@ -109,10 +141,11 @@ If the `sdd confluence draft` command fails or Confluence is not configured,
 fall back to the in-chat iteration below.
 
 **If no Confluence** — tell the user:
-> "Answer any of these you can — partial answers are fine, and 'not sure'
-> is a valid answer for technical questions (the architect will decide
-> later). Reply with your answers, or say 'good enough, proceed' to save
-> the draft as-is with the remaining [MISSING — ask user] markers for
+> "Group A is just a sanity check — keep the suggested defaults or swap in
+> your real numbers. Group B needs actual answers, but partial answers are
+> fine, and 'not sure' is a valid answer for technical questions (the
+> architect will decide later). Reply with your answers, or say 'good
+> enough, proceed' to save the draft as-is with the remaining markers for
 > later."
 
 ## Step 4 — Iterate
@@ -127,10 +160,12 @@ fall back to the in-chat iteration below.
    - Read every comment thread (footer comments AND inline comments)
    - For each comment: identify which context section it refers to, incorporate
      the feedback or answer into that section, remove the `[MISSING — ask user]`
-     marker if the comment resolves it
+     marker (or the `(SUGGESTED DEFAULT — edit or confirm)` marker, if the
+     comment confirms or overrides it) if the comment resolves it
    - After processing all comments, remove the `## Confluence Comments` section
      from the file (it has been incorporated — do not leave it in context.md)
-4. Note which `[MISSING — ask user]` markers are still open after applying comments
+4. Note which `[MISSING — ask user]` markers and unconfirmed
+   `(SUGGESTED DEFAULT — edit or confirm)` rows are still open after applying comments
 5. If any remain, show only those in a short updated checklist:
    > "Still a few open items — answer what you can, or say 'good enough' to proceed."
 6. Repeat until user says "good enough, proceed" or no markers remain
@@ -139,11 +174,13 @@ The user never needs to run `sdd confluence pull` manually — just say "done".
 
 **Via chat (if no Confluence):**
 On each reply:
-- Update context.md, resolving `[MISSING — ask user]` markers for
-  anything answered
+- Update context.md: resolve `[MISSING — ask user]` markers for anything
+  answered, and replace `(SUGGESTED DEFAULT — edit or confirm)` with
+  `(confirmed)` for any default the user explicitly kept, or with the
+  user's real value if they overrode it
 - Re-run Step 3 for anything still open
 - Repeat until the user says "good enough, proceed" or no
-  `[MISSING — ask user]` markers remain
+  `[MISSING — ask user]` markers or unconfirmed defaults remain
 
 ## Step 5 — Save
 Save the finished draft to `.specify/contexts/{feature}.md` (the file
@@ -173,10 +210,14 @@ with this header:
   into constitution Part 2 — resolve them at GATE-1."
 
 ## Never Do
-- Never invent business rules, NFR numbers, or constraints not stated or
-  reasonably inferable — use `[MISSING — ask user]` instead
-- Never skip the Missing Information Checklist, even if the draft looks
-  complete
+- Never invent business rules, actor/integration facts, or constraints not
+  stated or reasonably inferable — use `[MISSING — ask user]` instead
+- For Endpoints/NFRs specifically: proposing a generic scope-appropriate
+  starting point marked `(SUGGESTED DEFAULT — edit or confirm)` is expected
+  — but never present it as a confirmed fact or drop the marker before the
+  user has actually confirmed or overridden it
+- Never skip the Review Checklist (Group A + Group B), even if the draft
+  looks complete
 - Never overwrite an existing `.specify/contexts/{feature}.md` without
   confirming with the user first (offer to show a diff / merge instead)
 - Never read `.specify/contexts/{feature}.raw.md` in any command other than

{sddflow-2.7.1 → sddflow-2.7.2}/sdd/packs/sdd-backend-service/.specify/manifest.yml

@@ -43,5 +43,5 @@ testing_style: "paired"
 # If using sdd-universal instead, set project_type: "backend-service" in its manifest.yml
 # project_type: "backend-service"
 
-sdd_version: "2.7.0"   # set by sdd init; used by sdd upgrade
+sdd_version: "2.7.1"   # set by sdd init; used by sdd upgrade
 ai_tool: ""             # set by sdd init: claude-code | copilot | cursor | windsurf | other

{sddflow-2.7.1 → sddflow-2.7.2}/sdd/packs/sdd-backend-service/HOW-TO-USE.md

@@ -119,13 +119,13 @@ A detailed guide for every command: what it is, exactly when to run it, what it
 
 #### `/create-context` — Optional pre-phase
 
-**What:** You paste informal notes (emails, Confluence pages, rough bullets); the agent drafts a structured `context.md` and lists a plain-language "Missing Information" checklist. You iterate until complete.
+**What:** You paste informal notes (emails, Confluence pages, rough bullets); the agent drafts a structured `context.md`. For Endpoints and NFRs it also proposes scope-appropriate starting defaults (marked `SUGGESTED DEFAULT`) instead of leaving them blank, then lists a plain-language review checklist split into "confirm or edit these defaults" and "still need your input." You iterate until complete.
 
 **When to run:** Before `/specify`, only if you do not already have a `.specify/contexts/{feature}.md`.
 
 **Produces:** `.specify/contexts/{feature}.md`
 
-**You do next:** Review the draft — correct any wrong tech choices, fill in any [MISSING] items, add NFRs and business rules the agent didn't catch. Then fill `manifest.yml` and run `/specify`.
+**You do next:** Review the draft — confirm or override the suggested Endpoints/NFR defaults, correct any wrong tech choices, fill in any [MISSING] items, add business rules the agent didn't catch. Then fill `manifest.yml` and run `/specify`.
 
 **Skip if:** You already have a well-structured context file.
 

{sddflow-2.7.1/sdd/packs/sdd-mobile → sddflow-2.7.2/sdd/packs/sdd-frontend-spa}/.github/prompts/create-context.prompt.md

@@ -67,29 +67,59 @@ Map the raw input onto every section of context-template.md:
   10. Open Questions
   11. Tech Stack
 
-For each section:
-- Fill in anything the raw input states or clearly implies. Mark
-  agent-inferred content with "(inferred — confirm)".
-- If a section has nothing to go on, write `[MISSING — ask user]`.
-
-## Step 3 — Missing Information Checklist
-Produce a numbered, plain-language checklist — one question per
+For each section, fill it using the first tier below that applies:
+1. **Stated or clearly implied** — fill directly.
+2. **Agent-inferred** from something adjacent in the notes (e.g. an actor's
+   action in Key Flows implies an Endpoint, or a rule implies an NFR) —
+   fill it, mark "(inferred — confirm)".
+3. **Nothing stated or implied, but a safe generic starting point exists**
+   — applies ONLY to Endpoints and Non-Functional Requirements, never to
+   Actors, Business Rules, Constraints, Out of Scope, Open Questions, or
+   Tech Stack (those have no safe generic default — a wrong guess there
+   reads as a fabricated fact, not a placeholder number):
+   - **Endpoints**: derive one row per action verb found in Key Flows
+     (e.g. "submits X via API" → `POST /api/v1/{resource}`, "looks up Y"
+     → `GET /api/v1/{resource}`). If Key Flows gives nothing to derive
+     from either, propose one row per Actor named (a create + a read
+     endpoint is a reasonable starting shape for most services).
+   - **NFRs**: propose the same illustrative baseline this pack's own
+     templates use as examples, scaled to `manifest.project.scope`:
+     `pilot` → `P99 < 500ms`, `99% availability`, best-effort throughput;
+     `mvp`/`full` → `P99 < 300ms`, `99.9% availability`, `100 TPS peak`.
+   - Mark every row produced this way "(SUGGESTED DEFAULT — edit or
+     confirm)" — distinct from "(inferred — confirm)" so the user can
+     tell a guess grounded in their notes apart from a generic placeholder.
+4. **Nothing to go on and no safe default applies** — write
+   `[MISSING — ask user]`.
+
+## Step 3 — Review Checklist
+Split the open items into two groups so review effort goes where it's
+actually needed — don't make the user re-type things they'd only confirm:
+
+**Group A — Confirm or edit these starting defaults** (one line per
+`(SUGGESTED DEFAULT — edit or confirm)` marker). State the proposed value
+and invite a one-line override, e.g.:
+  1. (Endpoints) Proposed: `POST /api/v1/payments`, `GET
+     /api/v1/payments/{id}` — derived from your Key Flows. Keep these, or
+     tell me the real paths/verbs.
+  2. (NFRs) Proposed pilot-scope defaults: P99 < 500ms, 99% availability,
+     best-effort throughput. Keep these, or give me your real numbers.
+
+**Group B — Still need your input** (one question per
 `[MISSING — ask user]` marker, grouped by section, written for a
-non-technical reader. Examples:
+non-technical reader), for example:
   1. (Tech Stack) What programming language/framework will this use? If
      you're not sure, say "not sure — recommend one" and the architect can
      decide later at /plan-design.
   2. (Actors) Who are the different types of people or systems that will
      use this? (e.g. "customer", "admin", "support team", "another
      internal service")
-  3. (NFRs) Roughly how many users/requests per day? Any uptime
-     requirement (e.g. "must be up during business hours" vs "24/7")?
-  4. (Constraints) Any rules you must follow (legal, security, "must use
+  3. (Constraints) Any rules you must follow (legal, security, "must use
      our existing X system", budget/timeline)?
-  5. (Out of Scope) Anything people might assume is included but isn't,
+  4. (Out of Scope) Anything people might assume is included but isn't,
      for this first version?
 
-STOP here. Show the draft context.md AND the checklist.
+STOP here. Show the draft context.md AND both groups.
 
 ### Confluence Draft Option (if Confluence is configured)
 Check whether `.specify/integrations.yml` exists and has a `confluence:` section.
@@ -100,8 +130,10 @@ sdd confluence draft --doc context
 ```
 Then tell the user:
 > "I've pushed the draft to your Confluence space — open the link above.
-> Fill in the highlighted `[MISSING — ask user]` sections (you can share
-> the page with stakeholders directly in Confluence).
+> Review the highlighted `(SUGGESTED DEFAULT — edit or confirm)` rows
+> (Endpoints/NFRs — keep them or overwrite with your real numbers) and
+> fill in the `[MISSING — ask user]` sections (you can share the page
+> with stakeholders directly in Confluence).
 > When you're done editing, just say **'done'** here and I'll pull the
 > latest version automatically."
 
@@ -109,10 +141,11 @@ If the `sdd confluence draft` command fails or Confluence is not configured,
 fall back to the in-chat iteration below.
 
 **If no Confluence** — tell the user:
-> "Answer any of these you can — partial answers are fine, and 'not sure'
-> is a valid answer for technical questions (the architect will decide
-> later). Reply with your answers, or say 'good enough, proceed' to save
-> the draft as-is with the remaining [MISSING — ask user] markers for
+> "Group A is just a sanity check — keep the suggested defaults or swap in
+> your real numbers. Group B needs actual answers, but partial answers are
+> fine, and 'not sure' is a valid answer for technical questions (the
+> architect will decide later). Reply with your answers, or say 'good
+> enough, proceed' to save the draft as-is with the remaining markers for
 > later."
 
 ## Step 4 — Iterate
@@ -127,10 +160,12 @@ fall back to the in-chat iteration below.
    - Read every comment thread (footer comments AND inline comments)
    - For each comment: identify which context section it refers to, incorporate
      the feedback or answer into that section, remove the `[MISSING — ask user]`
-     marker if the comment resolves it
+     marker (or the `(SUGGESTED DEFAULT — edit or confirm)` marker, if the
+     comment confirms or overrides it) if the comment resolves it
    - After processing all comments, remove the `## Confluence Comments` section
      from the file (it has been incorporated — do not leave it in context.md)
-4. Note which `[MISSING — ask user]` markers are still open after applying comments
+4. Note which `[MISSING — ask user]` markers and unconfirmed
+   `(SUGGESTED DEFAULT — edit or confirm)` rows are still open after applying comments
 5. If any remain, show only those in a short updated checklist:
    > "Still a few open items — answer what you can, or say 'good enough' to proceed."
 6. Repeat until user says "good enough, proceed" or no markers remain
@@ -139,11 +174,13 @@ The user never needs to run `sdd confluence pull` manually — just say "done".
 
 **Via chat (if no Confluence):**
 On each reply:
-- Update context.md, resolving `[MISSING — ask user]` markers for
-  anything answered
+- Update context.md: resolve `[MISSING — ask user]` markers for anything
+  answered, and replace `(SUGGESTED DEFAULT — edit or confirm)` with
+  `(confirmed)` for any default the user explicitly kept, or with the
+  user's real value if they overrode it
 - Re-run Step 3 for anything still open
 - Repeat until the user says "good enough, proceed" or no
-  `[MISSING — ask user]` markers remain
+  `[MISSING — ask user]` markers or unconfirmed defaults remain
 
 ## Step 5 — Save
 Save the finished draft to `.specify/contexts/{feature}.md` (the file
@@ -173,10 +210,14 @@ with this header:
   into constitution Part 2 — resolve them at GATE-1."
 
 ## Never Do
-- Never invent business rules, NFR numbers, or constraints not stated or
-  reasonably inferable — use `[MISSING — ask user]` instead
-- Never skip the Missing Information Checklist, even if the draft looks
-  complete
+- Never invent business rules, actor/integration facts, or constraints not
+  stated or reasonably inferable — use `[MISSING — ask user]` instead
+- For Endpoints/NFRs specifically: proposing a generic scope-appropriate
+  starting point marked `(SUGGESTED DEFAULT — edit or confirm)` is expected
+  — but never present it as a confirmed fact or drop the marker before the
+  user has actually confirmed or overridden it
+- Never skip the Review Checklist (Group A + Group B), even if the draft
+  looks complete
 - Never overwrite an existing `.specify/contexts/{feature}.md` without
   confirming with the user first (offer to show a diff / merge instead)
 - Never read `.specify/contexts/{feature}.raw.md` in any command other than

{sddflow-2.7.1 → sddflow-2.7.2}/sdd/packs/sdd-frontend-spa/.specify/manifest.yml

@@ -32,5 +32,5 @@ testing_style: "paired"
 # If using sdd-universal instead, set project_type: "frontend-spa" in its manifest.yml
 # project_type: "frontend-spa"
 
-sdd_version: "2.7.0"   # set by sdd init; used by sdd upgrade
+sdd_version: "2.7.1"   # set by sdd init; used by sdd upgrade
 ai_tool: ""             # set by sdd init: claude-code | copilot | cursor | windsurf | other

{sddflow-2.7.1 → sddflow-2.7.2}/sdd/packs/sdd-frontend-spa/HOW-TO-USE.md

@@ -131,13 +131,13 @@ A detailed guide for every command: what it is, exactly when to run it, what it
 
 #### `/create-context` — Optional pre-phase
 
-**What:** You paste informal notes (emails, Confluence pages, rough bullets); the agent drafts a structured `context.md` and lists a plain-language "Missing Information" checklist. You iterate until complete.
+**What:** You paste informal notes (emails, Confluence pages, rough bullets); the agent drafts a structured `context.md`. For Endpoints and NFRs it also proposes scope-appropriate starting defaults (marked `SUGGESTED DEFAULT`) instead of leaving them blank, then lists a plain-language review checklist split into "confirm or edit these defaults" and "still need your input." You iterate until complete.
 
 **When to run:** Before `/specify`, only if you do not already have a `.specify/contexts/{feature}.md`.
 
 **Produces:** `.specify/contexts/{feature}.md`
 
-**You do next:** Review the draft — correct any wrong tech choices, fill in any [MISSING] items, add NFRs and business rules the agent didn't catch. Then fill `manifest.yml` and run `/specify`.
+**You do next:** Review the draft — confirm or override the suggested Endpoints/NFR defaults, correct any wrong tech choices, fill in any [MISSING] items, add business rules the agent didn't catch. Then fill `manifest.yml` and run `/specify`.
 
 **Skip if:** You already have a well-structured context file.
 

{sddflow-2.7.1/sdd/packs/sdd-frontend-spa → sddflow-2.7.2/sdd/packs/sdd-fullstack}/.github/prompts/create-context.prompt.md

@@ -67,29 +67,59 @@ Map the raw input onto every section of context-template.md:
   10. Open Questions
   11. Tech Stack
 
-For each section:
-- Fill in anything the raw input states or clearly implies. Mark
-  agent-inferred content with "(inferred — confirm)".
-- If a section has nothing to go on, write `[MISSING — ask user]`.
-
-## Step 3 — Missing Information Checklist
-Produce a numbered, plain-language checklist — one question per
+For each section, fill it using the first tier below that applies:
+1. **Stated or clearly implied** — fill directly.
+2. **Agent-inferred** from something adjacent in the notes (e.g. an actor's
+   action in Key Flows implies an Endpoint, or a rule implies an NFR) —
+   fill it, mark "(inferred — confirm)".
+3. **Nothing stated or implied, but a safe generic starting point exists**
+   — applies ONLY to Endpoints and Non-Functional Requirements, never to
+   Actors, Business Rules, Constraints, Out of Scope, Open Questions, or
+   Tech Stack (those have no safe generic default — a wrong guess there
+   reads as a fabricated fact, not a placeholder number):
+   - **Endpoints**: derive one row per action verb found in Key Flows
+     (e.g. "submits X via API" → `POST /api/v1/{resource}`, "looks up Y"
+     → `GET /api/v1/{resource}`). If Key Flows gives nothing to derive
+     from either, propose one row per Actor named (a create + a read
+     endpoint is a reasonable starting shape for most services).
+   - **NFRs**: propose the same illustrative baseline this pack's own
+     templates use as examples, scaled to `manifest.project.scope`:
+     `pilot` → `P99 < 500ms`, `99% availability`, best-effort throughput;
+     `mvp`/`full` → `P99 < 300ms`, `99.9% availability`, `100 TPS peak`.
+   - Mark every row produced this way "(SUGGESTED DEFAULT — edit or
+     confirm)" — distinct from "(inferred — confirm)" so the user can
+     tell a guess grounded in their notes apart from a generic placeholder.
+4. **Nothing to go on and no safe default applies** — write
+   `[MISSING — ask user]`.
+
+## Step 3 — Review Checklist
+Split the open items into two groups so review effort goes where it's
+actually needed — don't make the user re-type things they'd only confirm:
+
+**Group A — Confirm or edit these starting defaults** (one line per
+`(SUGGESTED DEFAULT — edit or confirm)` marker). State the proposed value
+and invite a one-line override, e.g.:
+  1. (Endpoints) Proposed: `POST /api/v1/payments`, `GET
+     /api/v1/payments/{id}` — derived from your Key Flows. Keep these, or
+     tell me the real paths/verbs.
+  2. (NFRs) Proposed pilot-scope defaults: P99 < 500ms, 99% availability,
+     best-effort throughput. Keep these, or give me your real numbers.
+
+**Group B — Still need your input** (one question per
 `[MISSING — ask user]` marker, grouped by section, written for a
-non-technical reader. Examples:
+non-technical reader), for example:
   1. (Tech Stack) What programming language/framework will this use? If
      you're not sure, say "not sure — recommend one" and the architect can
      decide later at /plan-design.
   2. (Actors) Who are the different types of people or systems that will
      use this? (e.g. "customer", "admin", "support team", "another
      internal service")
-  3. (NFRs) Roughly how many users/requests per day? Any uptime
-     requirement (e.g. "must be up during business hours" vs "24/7")?
-  4. (Constraints) Any rules you must follow (legal, security, "must use
+  3. (Constraints) Any rules you must follow (legal, security, "must use
      our existing X system", budget/timeline)?
-  5. (Out of Scope) Anything people might assume is included but isn't,
+  4. (Out of Scope) Anything people might assume is included but isn't,
      for this first version?
 
-STOP here. Show the draft context.md AND the checklist.
+STOP here. Show the draft context.md AND both groups.
 
 ### Confluence Draft Option (if Confluence is configured)
 Check whether `.specify/integrations.yml` exists and has a `confluence:` section.
@@ -100,8 +130,10 @@ sdd confluence draft --doc context
 ```
 Then tell the user:
 > "I've pushed the draft to your Confluence space — open the link above.
-> Fill in the highlighted `[MISSING — ask user]` sections (you can share
-> the page with stakeholders directly in Confluence).
+> Review the highlighted `(SUGGESTED DEFAULT — edit or confirm)` rows
+> (Endpoints/NFRs — keep them or overwrite with your real numbers) and
+> fill in the `[MISSING — ask user]` sections (you can share the page
+> with stakeholders directly in Confluence).
 > When you're done editing, just say **'done'** here and I'll pull the
 > latest version automatically."
 
@@ -109,10 +141,11 @@ If the `sdd confluence draft` command fails or Confluence is not configured,
 fall back to the in-chat iteration below.
 
 **If no Confluence** — tell the user:
-> "Answer any of these you can — partial answers are fine, and 'not sure'
-> is a valid answer for technical questions (the architect will decide
-> later). Reply with your answers, or say 'good enough, proceed' to save
-> the draft as-is with the remaining [MISSING — ask user] markers for
+> "Group A is just a sanity check — keep the suggested defaults or swap in
+> your real numbers. Group B needs actual answers, but partial answers are
+> fine, and 'not sure' is a valid answer for technical questions (the
+> architect will decide later). Reply with your answers, or say 'good
+> enough, proceed' to save the draft as-is with the remaining markers for
 > later."
 
 ## Step 4 — Iterate
@@ -127,10 +160,12 @@ fall back to the in-chat iteration below.
    - Read every comment thread (footer comments AND inline comments)
    - For each comment: identify which context section it refers to, incorporate
      the feedback or answer into that section, remove the `[MISSING — ask user]`
-     marker if the comment resolves it
+     marker (or the `(SUGGESTED DEFAULT — edit or confirm)` marker, if the
+     comment confirms or overrides it) if the comment resolves it
    - After processing all comments, remove the `## Confluence Comments` section
      from the file (it has been incorporated — do not leave it in context.md)
-4. Note which `[MISSING — ask user]` markers are still open after applying comments
+4. Note which `[MISSING — ask user]` markers and unconfirmed
+   `(SUGGESTED DEFAULT — edit or confirm)` rows are still open after applying comments
 5. If any remain, show only those in a short updated checklist:
    > "Still a few open items — answer what you can, or say 'good enough' to proceed."
 6. Repeat until user says "good enough, proceed" or no markers remain
@@ -139,11 +174,13 @@ The user never needs to run `sdd confluence pull` manually — just say "done".
 
 **Via chat (if no Confluence):**
 On each reply:
-- Update context.md, resolving `[MISSING — ask user]` markers for
-  anything answered
+- Update context.md: resolve `[MISSING — ask user]` markers for anything
+  answered, and replace `(SUGGESTED DEFAULT — edit or confirm)` with
+  `(confirmed)` for any default the user explicitly kept, or with the
+  user's real value if they overrode it
 - Re-run Step 3 for anything still open
 - Repeat until the user says "good enough, proceed" or no
-  `[MISSING — ask user]` markers remain
+  `[MISSING — ask user]` markers or unconfirmed defaults remain
 
 ## Step 5 — Save
 Save the finished draft to `.specify/contexts/{feature}.md` (the file
@@ -173,10 +210,14 @@ with this header:
   into constitution Part 2 — resolve them at GATE-1."
 
 ## Never Do
-- Never invent business rules, NFR numbers, or constraints not stated or
-  reasonably inferable — use `[MISSING — ask user]` instead
-- Never skip the Missing Information Checklist, even if the draft looks
-  complete
+- Never invent business rules, actor/integration facts, or constraints not
+  stated or reasonably inferable — use `[MISSING — ask user]` instead
+- For Endpoints/NFRs specifically: proposing a generic scope-appropriate
+  starting point marked `(SUGGESTED DEFAULT — edit or confirm)` is expected
+  — but never present it as a confirmed fact or drop the marker before the
+  user has actually confirmed or overridden it
+- Never skip the Review Checklist (Group A + Group B), even if the draft
+  looks complete
 - Never overwrite an existing `.specify/contexts/{feature}.md` without
   confirming with the user first (offer to show a diff / merge instead)
 - Never read `.specify/contexts/{feature}.raw.md` in any command other than

{sddflow-2.7.1 → sddflow-2.7.2}/sdd/packs/sdd-fullstack/.specify/manifest.yml

@@ -32,5 +32,5 @@ testing_style: "paired"
 # If using sdd-universal instead, set project_type: "fullstack" in its manifest.yml
 # project_type: "fullstack"
 
-sdd_version: "2.7.0"   # set by sdd init; used by sdd upgrade
+sdd_version: "2.7.1"   # set by sdd init; used by sdd upgrade
 ai_tool: ""             # set by sdd init: claude-code | copilot | cursor | windsurf | other

{sddflow-2.7.1 → sddflow-2.7.2}/sdd/packs/sdd-fullstack/HOW-TO-USE.md

@@ -133,13 +133,13 @@ A detailed guide for every command: what it is, exactly when to run it, what it
 
 #### `/create-context` — Optional pre-phase
 
-**What:** You paste informal notes (emails, Confluence pages, rough bullets); the agent drafts a structured `context.md` and lists a plain-language "Missing Information" checklist. You iterate until complete.
+**What:** You paste informal notes (emails, Confluence pages, rough bullets); the agent drafts a structured `context.md`. For Endpoints and NFRs it also proposes scope-appropriate starting defaults (marked `SUGGESTED DEFAULT`) instead of leaving them blank, then lists a plain-language review checklist split into "confirm or edit these defaults" and "still need your input." You iterate until complete.
 
 **When to run:** Before `/specify`, only if you do not already have a `.specify/contexts/{feature}.md`.
 
 **Produces:** `.specify/contexts/{feature}.md`
 
-**You do next:** Review the draft — correct any wrong tech choices, fill in any [MISSING] items, add NFRs and business rules the agent didn't catch. Then fill `manifest.yml` and run `/specify`.
+**You do next:** Review the draft — confirm or override the suggested Endpoints/NFR defaults, correct any wrong tech choices, fill in any [MISSING] items, add business rules the agent didn't catch. Then fill `manifest.yml` and run `/specify`.
 
 **Skip if:** You already have a well-structured context file.