jsdlc-implement

# Implementation from Design (製造) Request / arguments: $ARGUMENTS Mode is the first word: `create` (default), `review`, `modify`. Read before acting: - the target `DD-<DOM>-<nnn>` detail design and any related API spec - `docs-jsdlc/rules/review-checklist.md` §2 and §7 - the project profile `.kiro/steering/jsdlc-project-profile.md` §2–§4 (source and test roots, build and test commands, trace tag) and the conventions document it names, if any. A `<...>` placeholder in one of those items stops this skill: report it, raise `Q-NNN`, write no code In this SDLC the design is authoritative. Code is a faithful realization of an approved document, **not** an opportunity to improve the design. A better idea found while coding is raised as an Open Question against the design, not implemented directly. This is the rule engineers most often break, and the one Japanese reviewers check hardest. --- ## Mode: create ### Step 1 — Verify the design is implementable Read the detail design completely before writing anything. Check that §3 field tables, §5 flow, §6 rules, §7 abnormal cases, and §8 boundaries are all present and decidable. If something required to write correct code is missing or ambiguous: **Stop. Raise `Q-NNN` against the design. Do not choose for the client.** Proceed only with a provisional assumption that is written down, both in the open-questions register and in the report. An undocumented choice made at this step is the defect this kit exists to prevent. ### Step 2 — Locate the implementation site Read the existing code around the target: the layer boundaries, naming, error handling, and test style already in use. Follow them. Introducing a new pattern because it is objectively nicer is out of scope (I-06). ### Step 3 — Implement Work section by section through the design, not feature by feature: - **§3.1 inputs** → validation at the boundary the design names, with exactly the error code the design assigns. Not a different code, not a generic one. - **§5.2 / §5.3 flow** → the same steps in the same order. If the code's order must differ (e.g. for a lock), note it and raise a question. - **§6 business rules** → each rule as a distinct, readable check. Boundary inclusivity exactly as written: `[start, end)` means `start < other.end && other.start < end`, and getting this backwards is the classic defect. - **§7 abnormal cases** → every row exists in code with its stated code and status. Count them: rows in §7 should equal error exits in the code. - **§4 data access** → the tables, operations, and keys the design names. Tag every class or method implementing a design item with the trace tag the project profile §4 defines — by default a doc comment carrying `@design DD-<DOM>-<nnn>-<nn>`. This tag is what makes code-to-design traceability mechanical (I-02). ### Step 4 — Implement the unit tests If a UT document exists, implement its cases — same case IDs in the test names, so the mapping is checkable. If it does not exist, write tests covering the design's 正常系 / 異常系 / 境界値 and report that the UT document is missing. ### Step 5 — Verify Run the build and unit test commands from the project profile §3. Report actual output against the recorded baseline. A failing test is reported as failing, never worked around by weakening the assertion. ### Step 6 — Report Design items implemented, files touched, abnormal cases implemented vs. designed (the counts must match), tests added and their result, and every question raised. If you used a provisional assumption, it goes in the first line. --- ## Mode: review Do not edit code. Compare implementation against design, in this direction and then the reverse — both directions find different defects: **Design → code:** every §6 rule, §7 abnormal case, §8 boundary, and §3 validation exists in code with the same code and condition. Missing = NG. **Code → design:** every behaviour, branch, and error exit in the code appears in the design. Extra behaviour is NG (I-04, over-implementation) — it is untested, unreviewed, and unknown to the client. Also check: trace tags present in the profile §4 form (I-02); validation at the designed boundary (I-05); UT cases exist and pass (I-07); project conventions followed (I-06). Run the tests as part of the review and report the actual result. Write to `docs-jsdlc/output/review/DD-<DOM>-<nnn>-code-review-<YYYYMMDD>.md`. --- ## Mode: modify 1. Fix every NG. Each change traces 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 要確認 to `Q-NNN` — do not resolve a business ambiguity in code. 3. **When code and design disagree, neither side is changed in this step.** Write the mismatch as a finding, register a `Q-NNN` naming both readings and the provisional one, and stop. A person names the authoritative side in the register row (decider, decision, date). Only then modify the side they named: - the code — only if the design carries the approval evidence the project profile §10 lists. A design without it is a draft, and code is never changed to match a draft; - the design — through its own skill's `modify` mode, if the code was confirmed right. A design that contradicts its own parent or itself is reported the same way, not interpreted. Never "fix" a design by editing code to match intent you inferred, and never pick a side because the report already names both. 4. Re-run the unit test command from the profile §3 after changes and report the real result against the baseline. 5. Report: findings fixed, questions promoted, test results before and after, and any design document that now needs updating.