jsdlc-basic-design

# Basic Design (基本設計書) Request / arguments: $ARGUMENTS Mode is the first word: `create` (default), `review`, `modify`. Read before acting: - `docs-jsdlc/templates/basic-design.md` - `docs-jsdlc/rules/id-and-traceability.md` - `docs-jsdlc/rules/review-checklist.md` §2 and §3 - `docs-jsdlc/rules/diagram-rules.md`, when profile §7 says PlantUML is used Basic design answers **what the system does, seen from outside**. It never specifies how a component is built internally — that is detail design. Pushing internal structure up into basic design is as much a defect as leaving a external behaviour undefined. --- ## Mode: create ### Step 1 — Establish the source Two legitimate inputs: - **From requirements** — a requirements document or the user's description. When the project profile §8 names an IPO or parameter sheet, that sheet is part of the requirements: read it, and where it contradicts the prose, raise a `Q-NNN` naming the sheet and the row rather than choosing a side. Never write back to a client sheet. - **From an existing system** (reverse engineering) — read the code and derive the external behaviour. State clearly in §1.1 that the document is derived from implementation, and treat every derived item as 要確認 until a human confirms it reflects intent, not accident. If neither is available, stop and ask for one. Do not invent requirements. ### Step 2 — Fix the domain code Read the 3-6 char `DOMAIN` code from `docs-jsdlc/project/domain-codes.md`. If the area has no code yet, propose one, register a `Q-NNN` for the owner to confirm it, and add the row marked provisional; never invent one silently. All IDs in the chain depend on it. ### Step 3 — Build the lists in dependency order Order matters; each list feeds the next. 1. **Function list (§4)** — one row per externally triggerable behaviour. 2. **Entity list (§6)** — one row per persistent thing. 3. **State model (§5)** — for every entity with a lifecycle. Fill the full transition matrix. Every blank cell is a prohibited transition and needs an error code — this is where most abnormal cases are discovered. 4. **CRUD matrix (§7)** — every function × entity. An entity nothing creates, or nothing reads, is a design defect: report it rather than papering over it. 5. **Message list (§8)** — one row per way the system says no. Derive them systematically from the prohibited transitions in §5, the validation implied by §4, and every external interface failure in §9. This list is the single source of error codes for the entire downstream chain; a code missing here cannot be invented later. 6. **Non-functional (§10)** — numbers with units and a measurement method. "Fast" is a finding; "p95 < 500 ms measured at the ALB" is a requirement. Once the lists are complete, and only then, draw the diagrams the project profile §7 asks for, following `docs-jsdlc/rules/diagram-rules.md`: an activity diagram of the §3 business flow, with the §3.2 actors as swimlanes, and an ER diagram of the §6 entities, with cardinality on every relationship. Both are derived from the tables — a diagram that shows an entity, an actor or a branch the tables do not contain means a table is incomplete. Fix the table, then redraw. When §7 says PlantUML is not used, the §3.1 flow stays an ASCII sketch and there is no ER file. ### Step 4 — Traceability and questions Fill §2 mapping every BD item to a source requirement. An item with no source is either scope creep or a missing requirement — raise `Q-NNN` either way. List everything undetermined in §12 with a provisional assumption. ### Step 5 — Self-check and save Run §2 and §3 checklists on your draft. Save to `docs-jsdlc/output/basic-design/BD-<DOM>-<nnn>-<slug>.md`. Append new questions to `docs-jsdlc/output/open-questions.md`. ### Step 6 — Report Function count, entity count, state count, message count, questions raised, and any CRUD gap found. --- ## Mode: review Do not edit. Run §2 (common) and §3 (basic design) checks one at a time, recording evidence for each. Pay particular attention to the checks that are cheap to fake and expensive to miss: - **B-02 consistency** — cross-read the function, entity, and message lists against each other. Names that drift between lists are NG. - **B-03 CRUD completeness** — actually walk the matrix; do not trust it. - **B-04 message completeness** — for every prohibited state transition in §5, confirm a message exists. Missing ones are the classic gap. - **B-05 non-functional** — any adjective without a number is a finding. Write to `docs-jsdlc/output/review/BD-<DOM>-<nnn>-review-<YYYYMMDD>.md` using the review report template. State checks run and checks not applicable. --- ## Mode: modify 1. Fix every NG, traceable to a finding number. Every NG you close carries the follow-through its class requires — see `docs-jsdlc/rules/review-checklist.md` §9. Closing the symptom without the follow-through leaves the defect class open, and the next review will find it again. A deferral counts as closed only with a `Q-NNN`, a named decider, and a due phase. 2. Promote every 要確認 to `Q-NNN`; never decide one yourself. 3. **Impact analysis is mandatory at this level.** Basic design has children. For every change, list the affected DD, API, and test documents, and report them as requiring re-examination. A change to §8 (messages) or §5 (states) almost always invalidates downstream documents — say which. 4. Bump the revision history naming the findings addressed. 5. Report: fixes applied, questions promoted, and the downstream documents the user must now re-run through review.