Examples
These examples are upstream SDTK-SPEC scenario packs. They show the scaffold and governed phase structure that later hands into SDTK-CODE and, when needed, SDTK-OPS.
Canonical SDTK-SPEC scenario for the full upstream artifact chain across BA, architecture, API, database, screen layout, flow-action, DEV planning, and QA release gating.
This is the same family of work that downstream SDTK-CODE and SDTK-OPS later validated on the real Workflow project.
Focused upstream scenario for backend-heavy delivery where UI-specific artifacts are intentionally reduced while API contract discipline stays explicit.
Use this pack when SDTK-SPEC is the active product surface and the coding or ops layers have not started yet.
UI-heavy upstream scenario emphasizing DESIGN_LAYOUT, FLOW_ACTION_SPEC, action mapping, and cross-screen process clarity before implementation begins.
This pack is still upstream truth. Once the handoff is approved, SDTK-CODE becomes the correct product surface for coding execution.
Documents the shortened upstream documentation path for bugfix delivery while preserving mandatory verification, handoff, and QA release discipline.
The downstream bugfix lane in SDTK-CODE remains lighter than the feature lane, but the upstream boundary still starts here.
Companion product pages
Examples stay upstream. Use the dedicated product pages below when the work shifts from scaffold review into coding execution or operational validation.
Stay here when the active need is scaffold generation, planning contracts, and governed upstream document handoff.
Open page ->PublicMove here when the formal handoff is approved and implementation work becomes the active concern.
Open page ->PublicMove here when deployment, local Docker validation, incident work, or operations closeout becomes the active concern through the public SDTK-OPS package line.
Open page ->