jsdlc-detail-design

# Detail Design (詳細設計書) Request / arguments: $ARGUMENTS Mode is the first word of the arguments: `create` (default), `review`, `modify`. Read before acting: - `docs-jsdlc/templates/detail-design.md` — the required structure - `docs-jsdlc/rules/id-and-traceability.md` — ID and parent rules - `docs-jsdlc/rules/review-checklist.md` §2 and §4 — the checks you are graded on - `docs-jsdlc/rules/diagram-rules.md`, when profile §7 says PlantUML is used --- ## Mode: create ### Step 1 — Establish the input Identify the parent basic design item (`BD-<DOM>-<nnn>`). If the user did not name one, look in `docs-jsdlc/output/basic-design/`. If no basic design exists, stop and say so — do not invent a parent. Offer `/jsdlc-basic-design` instead. Read the parent item fully: its function outline, state model, message list, entity list, CRUD row, and non-functional items. The message list matters most: **you may not invent error codes**, only use codes the basic design defines. ### Step 2 — Survey the existing implementation If code for this function already exists, read it. A detail design that contradicts working code without saying so is a defect. Where they differ, record which is authoritative in an Open Question. ### Step 3 — Decide what is undetermined Before writing, list everything the basic design does not settle: boundary inclusivity, null behaviour, transaction scope, concurrency, ordering, timezone, rounding, retry. Each becomes `Q-NNN`, with a provisional assumption so the document stays usable. Never resolve one by picking silently. ### Step 4 — Write Fill every section of the template in order. Non-negotiable quality bars: - **§3.1 field table** — every field needs type, length/range, required, default, validation rule, and the error code raised on violation. An optional field additionally needs null / empty / zero behaviour. - **§5.2 steps** — one action per step, imperative. Every step names what happens on failure, including what is rolled back. When the project profile §7 says PlantUML is used, draw the flow as a sequence diagram once the steps are complete, following `docs-jsdlc/rules/diagram-rules.md` — every error exit in the steps becomes a branch carrying the same error code. If the component holds state, the state transition table gets a state diagram too. When §7 says `no`, write steps and tables only; do not invent diagram files. - **§5.3 pseudo code** — every branch that ends in an error names the code (`-> error E1004`). A reader must be able to count the exits. - **§6 business rules** — formal, decidable statements. Write boundaries in symbols: `start < end, end exclusive`, not "the end must be later". - **§7 abnormal cases** — one row per way this function can fail, each with a detection point and an error code that exists in the parent. - **§8 boundary conditions** — every numeric or temporal limit, with inclusivity stated. The sufficiency test: could a different engineer implement this without asking you anything that is not already in §12? If not, keep writing. ### Step 5 — Self-check then write the file Run the §4 checklist against your own draft. Fix every NG before saving. Save to `docs-jsdlc/output/detail-design/DD-<DOM>-<nnn>-<slug>.md`. Append any new `Q-NNN` to `docs-jsdlc/output/open-questions.md`. ### Step 6 — Report State: the DD ID, the parent BD ID, section count filled, number of abnormal cases, number of boundary conditions, and every open question raised. If you made a provisional assumption, say so in the first line — do not bury it. --- ## Mode: review Do not edit the document. Produce a review report only. 1. Read the target document and its parent basic design. 2. Run every check in `review-checklist.md` §2 (common) and §4 (detail design). Run them one at a time; do not skim. For each, record OK / NG / 要確認 with the evidence — a quote or a section reference. 3. Verify traceability by actually resolving the parent ID in the parent file. A parent ID that does not exist is NG, not a typo to fix silently. 4. Verify every error code appears in the parent message list. 5. Cross-check against the implementation if it exists: behaviour in code but not in the design is NG (over-implementation, I-04). 6. Write the report using `docs-jsdlc/templates/review-report.md` to `docs-jsdlc/output/review/DD-<DOM>-<nnn>-review-<YYYYMMDD>.md`. Report the count of checks run and which were not applicable. "No problems found" without those counts is not an acceptable review. --- ## Mode: modify Input: a document plus either a review report or explicit instructions. 1. Read the review report. Build a list of findings by severity. 2. **Fix every NG.** Each fix must be 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. 3. **Never fix a 要確認.** Promote it to `Q-NNN` in §12 and add it to the open-questions register. If a 要確認 blocks an NG fix, state the dependency and leave both open. 4. Bump the revision history: new version, today's date, and a change summary that names the finding numbers addressed. 5. Re-check the sections you touched against the checklist — a fix that introduces a new NG is worse than the original finding. 6. Fill §5 of the review report (Applied Fixes) with what you changed. 7. Report: findings fixed, findings promoted to questions, findings left open and why, and the new version number. If applying a finding would contradict the parent basic design, stop. Report the conflict and raise an Open Question. Downstream never overrules upstream.