domain-architecture-workflowlisted

# Domain Architecture Workflow ## Purpose Use this skill as the entry point for business-domain software architecture work. It coordinates domain modeling, architecture guidance, and optional framework-specific landing without depending on any external workflow skill. If another planning, TDD, or review workflow is already active, use this skill only for the domain and architecture decisions inside that workflow. ## Workflow 1. Understand the business goal, acceptance expectations, actors, workflows, constraints, and uncertainty; classify how much domain and architecture work the requested increment needs. 2. Use `domain-modeling` for non-trivial business behavior and consume its `Domain Modeling Result`. 3. Use `domain-architecture-guidance` to choose appropriate boundaries and consume its `Architecture Guidance Result`. 4. Use `using-jfoundry` only when applicable and after domain and architecture assumptions are clear. If jfoundry use is undecided, continue framework-neutral phases without invoking it and defer the choice until a framework-specific next activity materially requires it. 5. Produce a composite `Domain Architecture Handoff` that makes planning readiness, dependent blockers, and the next owner explicit. 6. Persist workflow-owned artifacts under the default documentation directory, then route detailed planning to its `plans` subdirectory or to the user-selected process companion. The companion alone owns its plan files, tasks, and execution state. 7. Durin