Sssdd Detail

Rules

• Be explicit about states, transitions, and failure cases.
• Still avoid runtime topology, technology picks, and code file decisions.
• Make this layer strong enough that architecture can map responsibilities cleanly.
• Write the generated markdown content in Japanese.
• Keep the tree branching so different behaviors can lead to different architecture nodes later.
• Parent Coverage should make it obvious which portion of the parent design node is being refined.
• Relevant Non-Functional Requirements should translate parent quality attributes into concrete behavior expectations, limits, consistency needs, timing sensitivity, audit needs, or failure budgets where relevant.
• Keep terminology aligned with 01-glossary.md, and update the glossary when detailed behavior forces a clearer canonical term, wording distinction, or stable implementation-facing identifier hint.
• When a parent file is still too broad, present the proposed sub-branches before writing to keep the conversation collaborative.
• Update existing child files in place when the parent slice still exists.
• Do not rewrite the full design node in every detail-design file. Add only the state, rule, contract, and failure precision owned here.
• When a changed fact is still owned by design, keep the correction in the parent and only update downstream refinements that depend on it.
• Use Open Questions only for issues that remain unresolved after the current discussion pass.
• Use Assumptions only for temporary working assumptions adopted after discussion.
• If discussion resolves an item, move it into the main body and remove it from these sections.
• Inputs and Outputs, Validation Rules, and Failure Handling should be specific enough that architecture does not need to reinterpret business behavior.
• Use Operational Notes for runtime-sensitive behavior implied by upstream non-functional requirements, such as latency-sensitive paths, retry boundaries, timeout expectations, concurrency assumptions, or audit event expectations.
• Exit Checks should prove the node is architecturally mappable.

Report

Report:

• target project directory
• child files created or updated
• which design nodes were refined
• sub-branching introduced under each refined design node
• non-functional requirements sharpened into behavioral rules
• questions asked or assumptions made
• traceability and exit readiness summary
• recommended next skill: $sssdd-architecture