dew-method 0.1.0

package/src/dew-skills/3-solutioning/dew-create-epics-and-stories/steps/step-01-init.md

@@ -0,0 +1,67 @@
+# Step 01 — Epics and Stories Initialization
+
+## Mandatory Rules
+
+- Do not create implementation backlog before DataOps design exists.
+- Do not proceed if key design artifacts are missing.
+- Read the complete step before acting.
+
+## Task
+
+Initialize Epics and Stories workflow.
+
+## Sequence
+
+### 1. Detect existing workflow
+
+Look for:
+- `{workflow.epics_output_path}/**/epics.md`
+- `{planning_artifacts}/**/*epics*.md`
+- `{planning_artifacts}/**/*story-map*.md`
+
+If unfinished workflow exists, offer to resume.
+
+### 2. Validate prerequisites
+
+Look for:
+- `dataops-runbook.md`
+- `serving-data-product-spec.md`
+- `data-quality-rules.md`
+- `data-model-spec.md`
+- `transformation-design.md`
+- `ingestion-design.md`
+- `storage-design.md`
+- `data-architecture.md`
+
+If missing, trigger `HALT-17 — Implementation Not Ready`.
+
+### 3. Create workspace
+
+Bind `{doc_workspace}` to:
+
+`{workflow.epics_output_path}/{workflow.run_folder_pattern}/`
+
+Create:
+- `epics.md`
+- `story-map.md`
+
+Use templates.
+
+### 4. Initialize frontmatter
+
+Set:
+
+```yaml
+status: draft
+stepsCompleted:
+  - step-01-init
+decisionGates:
+  GATE-23-implementation-readiness:
+    status: pending
+```
+
+### 5. Continue checkpoint
+
+Ask:
+
+`[C] Continue to load design artifacts`

package/src/dew-skills/3-solutioning/dew-create-epics-and-stories/steps/step-02-load-design-artifacts.md

@@ -0,0 +1,64 @@
+# Step 02 — Load Design Artifacts
+
+## Mandatory Rules
+
+- Load all designs before creating epics.
+- Do not invent implementation scope.
+- Carry caveats forward.
+
+## Task
+
+Extract implementation context.
+
+## Extract
+
+From storage:
+- layers
+- source-to-storage mapping
+- metadata requirements
+
+From ingestion:
+- source plans
+- schema evolution
+- idempotency
+- replay/backfill
+
+From transformation:
+- Bronze→Silver rules
+- Silver→Gold rules
+- business rules
+
+From model:
+- Silver/Gold models
+- KPI-to-model mapping
+- bridge/history needs
+
+From DQ:
+- DQ rules
+- severity/action
+- evidence requirements
+
+From serving:
+- serving mode
+- metric contract
+- trust statement
+
+From governance:
+- access/privacy/lineage requirements
+
+From DataOps:
+- monitoring
+- runbook
+- operational mode
+
+## Update
+
+Update:
+- epics.md
+- story-map.md
+
+## Continue checkpoint
+
+Ask:
+
+`[C] Continue to build epic map`

package/src/dew-skills/3-solutioning/dew-create-epics-and-stories/steps/step-03-build-epic-map.md

@@ -0,0 +1,48 @@
+# Step 03 — Build Epic Map
+
+## Mandatory Rules
+
+- Every epic must map to design artifacts.
+- Every epic must produce evidence.
+- Do not create vague epics.
+
+## Task
+
+Create epic map.
+
+## Recommended epics
+
+1. Foundation and Project Setup
+2. Source Access and Bronze Ingestion
+3. Source Contract and DQ Prechecks
+4. Silver Transformation
+5. Gold Modeling and KPI Computation
+6. Data Quality Evidence
+7. Serving Data Product
+8. Governance Documentation
+9. DataOps and Observability
+
+## For each epic
+
+Define:
+- goal
+- design inputs
+- scope
+- out of scope
+- story candidates
+- acceptance criteria
+- evidence expected
+- risks/caveats
+- dependencies
+
+## Update
+
+Update:
+- epics.md
+- story-map.md
+
+## Continue checkpoint
+
+Ask:
+
+`[C] Continue to story slicing gate`

package/src/dew-skills/3-solutioning/dew-create-epics-and-stories/steps/step-04-story-slicing-gate.md

@@ -0,0 +1,49 @@
+# Step 04 — Story Slicing Gate
+
+## Mandatory Rules
+
+- Stop at this gate.
+- User must approve story slicing strategy.
+- Stories must be small enough to implement and validate.
+- Stories must not mix unrelated lifecycle layers.
+
+## Story slicing options
+
+A. Slice by lifecycle layer  
+B. Slice by source  
+C. Slice by KPI/data product output  
+D. Slice by vertical path source→serving  
+E. Hybrid slicing  
+
+## Recommendation guide
+
+- Use lifecycle slicing for learning clarity.
+- Use source slicing when sources are independent.
+- Use KPI slicing when data product is metric-centric.
+- Use vertical slicing when proving E2E value quickly.
+- Use hybrid when project is complex.
+
+## Required table
+
+| Option | Pros | Cons | Fit | Risk |
+|---|---|---|---|---|
+
+## User decision
+
+Ask user to choose A/B/C/D/E.
+
+Do not continue until user chooses.
+
+## Record
+
+Update:
+- epics.md
+- story-map.md
+- .decision-log.md
+- .learning-log.md if enabled
+
+## Continue checkpoint
+
+Ask:
+
+`[C] Continue to create story map`

package/src/dew-skills/3-solutioning/dew-create-epics-and-stories/steps/step-05-create-story-map.md

@@ -0,0 +1,49 @@
+# Step 05 — Create Story Map
+
+## Mandatory Rules
+
+- Every story candidate must have dependency and evidence requirement.
+- Do not mark story ready-for-dev here.
+- Story readiness is handled by `dew-create-data-story`.
+
+## Task
+
+Create full story map.
+
+## Required fields
+
+| Story ID | Epic ID | Title | Layer | Depends On | Design Input | Evidence Required | Status |
+|---|---|---|---|---|---|---|---|
+
+## Story status
+
+Initial status:
+- backlog
+
+## Suggested story ID format
+
+`{epic_number}.{story_number}`
+
+Examples:
+- 1.1 Initialize project structure
+- 2.1 Implement source access for SRC-001
+- 2.2 Ingest SRC-001 into Bronze
+- 3.1 Implement source contract tests for SRC-001
+- 4.1 Transform Bronze SRC-001 to Silver
+- 5.1 Build Gold KPI mart
+- 6.1 Implement DQ rule catalog tests
+- 7.1 Create serving asset
+- 8.1 Create trust and limitations documentation
+- 9.1 Implement run logs and observability evidence
+
+## Update
+
+Update:
+- story-map.md
+- epics.md
+
+## Continue checkpoint
+
+Ask:
+
+`[C] Continue to readiness and dependency review`

package/src/dew-skills/3-solutioning/dew-create-epics-and-stories/steps/step-06-readiness-and-dependency-review.md

@@ -0,0 +1,54 @@
+# Step 06 — Readiness and Dependency Review
+
+## Mandatory Rules
+
+- Implementation readiness must be explicit.
+- Blockers must not be hidden.
+- Every story must have evidence requirement.
+- Missing evidence requirement triggers HALT-18.
+
+## Task
+
+Review epic/story readiness.
+
+## Review table
+
+| Epic | Ready? | Blocker | Caveat | Next Action |
+|---|---|---|---|---|
+
+## Dependency review
+
+Check:
+- no story depends on missing design
+- no transformation story before ingestion story
+- no Gold story before Silver story
+- no serving story before Gold/DQ story
+- no operational story without DataOps design
+
+## Implementation readiness gate
+
+Options:
+
+A. Ready for sprint planning  
+B. Ready with caveats  
+C. Return to design phase  
+D. Reduce MVP scope  
+E. Block implementation  
+
+Ask user to choose.
+
+Do not continue until user chooses.
+
+## Record
+
+Update:
+- epics.md
+- story-map.md
+- .decision-log.md
+- .learning-log.md if enabled
+
+## Continue checkpoint
+
+Ask:
+
+`[C] Continue to finalize epics and stories`

package/src/dew-skills/3-solutioning/dew-create-epics-and-stories/steps/step-07-finalize.md

@@ -0,0 +1,36 @@
+# Step 07 — Finalize Epics and Stories
+
+## Mandatory Rules
+
+- Do not finalize if implementation readiness gate is unresolved.
+- Do not mark individual stories ready-for-dev here.
+- Run checklist.
+
+## Required outputs
+
+- epics.md
+- story-map.md
+- decision log entries
+- learning log entries if enabled
+
+## Final status
+
+Set:
+
+```yaml
+status: final
+stepsCompleted:
+  - step-01-init
+  - step-02-load-design-artifacts
+  - step-03-build-epic-map
+  - step-04-story-slicing-gate
+  - step-05-create-story-map
+  - step-06-readiness-and-dependency-review
+  - step-07-finalize
+```
+
+## Next workflow
+
+Recommend:
+
+`dew-sprint-planning`

package/src/dew-skills/3-solutioning/dew-data-architecture/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: dew-data-architecture
+description: Create evidence-grounded data architecture from requirement gate, KPI feasibility, source validation, and approved caveats.
+---
+
+# DEW Data Architecture
+
+**Goal:** Create a data architecture that is grounded in validated KPI/source evidence and approved requirement gates.
+
+**Your Role:** You are a data architecture facilitator.
+
+You do not invent requirements. You translate validated/caveated requirements into architecture decisions.
+
+You may recommend, but you must not decide.
+
+## Workflow Architecture
+
+This workflow uses step-file architecture.
+
+Rules:
+- Read one step file at a time.
+- Read the complete step file before acting.
+- Do not skip steps.
+- Do not load future steps early.
+- Stop at decision gates.
+- Do not create architecture without Requirement Gate approval.
+- Update frontmatter after each completed step.
+- Build documents append-only unless user asks to revise.
+
+## Conventions
+
+- Bare paths resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory.
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{workflow.<name>}` resolves to fields in `customize.toml`'s `[workflow]` table.
+- `{doc_workspace}` is the run folder for this workflow.
+
+## Mandatory Rules
+
+- Do not create architecture before `dew-requirement-gate` is approved.
+- Do not silently drop caveats from requirement gate.
+- Do not promote unvalidated KPI/source assumptions into architecture facts.
+- Do not choose technology without trade-off explanation and user approval.
+- Do not design storage/ingestion/transformation in full detail here; capture architecture-level decisions and defer detailed designs to later skills.
+- If Requirement Gate is missing or blocked, trigger `HALT-10 — Architecture Before Validation`.
+- If trust expectation is missing, trigger `HALT-08 — Trust Expectation Required`.
+- If grain is undefined, trigger `HALT-07 — Grain Undefined`.
+- If source validation is missing, trigger `HALT-06 — Source Trust Not Established`.
+- If evidence is missing, trigger `HALT-18 — No Validation Evidence`.
+
+## On Activation
+
+1. Resolve customization:
+
+   `python3 {project-root}/_dew/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+   If the script fails, read `{skill-root}/customize.toml` directly and use defaults.
+
+2. Execute each entry in `{workflow.activation_steps_prepend}` in order.
+
+3. Treat every entry in `{workflow.persistent_facts}` as foundational context for the rest of the run. Entries prefixed `file:` are paths or globs under `{project-root}`.
+
+4. Load `{project-root}/_dew/dew/config.yaml` if present and resolve:
+   - `{user_name}`
+   - `{project_name}`
+   - `{communication_language}`
+   - `{document_output_language}`
+   - `{planning_artifacts}`
+   - `{implementation_artifacts}`
+   - `{evidence_artifacts}`
+   - `{learning_artifacts}`
+   - `{learning_mode}`
+
+5. Load:
+   - `{workflow.architecture_template}`
+   - `{workflow.adr_template}`
+   - `{workflow.caveat_carryover_template}`
+   - `{workflow.architecture_pattern_rubric}`
+   - `{workflow.technology_decision_rubric}`
+   - `{workflow.lifecycle_guide}`
+
+6. Greet `{user_name}` in `{communication_language}`.
+
+7. Execute each entry in `{workflow.activation_steps_append}` in order.
+
+## Execution
+
+Read fully and follow:
+
+`steps/step-01-init.md`

package/src/dew-skills/3-solutioning/dew-data-architecture/assets/architecture-caveat-carryover-template.md

@@ -0,0 +1,44 @@
+# Architecture Caveat Carryover Template
+
+```markdown
+# Architecture Caveat Carryover
+
+## Purpose
+
+This file ensures caveats approved in Requirement Gate are not lost during architecture.
+
+Accepted caveats are not evidence.
+
+They are known limitations that must be carried into later design and implementation.
+
+## Caveat Table
+
+| Caveat ID | Source | Area | Description | Severity | Architecture Impact | Later Skill Responsible |
+|---|---|---|---|---|---|---|
+| CAV-001 | Requirement Gate | KPI/Source/Grain/Freshness | | High/Medium/Low | | |
+
+## Caveat Entry
+
+## CAV-{number} — {Short Name}
+
+Source:
+
+Area:
+
+Description:
+
+Severity:
+
+Accepted by user:
+
+Architecture impact:
+
+Must appear in:
+- storage design:
+- ingestion design:
+- transformation design:
+- serving design:
+- governance/security design:
+- implementation stories:
+
+Revisit trigger:

package/src/dew-skills/3-solutioning/dew-data-architecture/assets/architecture-decision-record-template.md

@@ -0,0 +1,89 @@
+# Architecture Decision Record Template
+
+```markdown
+---
+title: "{Project Name} Architecture Decision Records"
+status: active
+created: {YYYY-MM-DD}
+updated: {YYYY-MM-DD}
+workflow: dew
+phase: "3-solutioning"
+---
+
+# Architecture Decision Records
+
+## ADR-0001 — {Decision Title}
+
+Date:
+
+Status:
+- proposed
+- accepted
+- accepted-with-caveats
+- rejected
+- superseded
+
+## Context
+
+What validated requirement, source evidence, KPI feasibility, or caveat triggered this decision?
+
+## Decision
+
+What was decided?
+
+## Options Considered
+
+### A. {Option A}
+
+Pros:
+
+Cons:
+
+### B. {Option B}
+
+Pros:
+
+Cons:
+
+### C. {Option C}
+
+Pros:
+
+Cons:
+
+## Selected Option
+
+## Rationale
+
+## Evidence Used
+
+- requirement gate:
+- KPI feasibility:
+- source validation:
+- evidence index:
+- decision log:
+
+## Consequences
+
+Positive:
+
+Negative:
+
+Trade-offs:
+
+## Reversibility
+
+- Easy
+- Medium
+- Hard
+
+## Revisit Trigger
+
+## Downstream Impact
+
+- Storage:
+- Ingestion:
+- Transformation:
+- Serving:
+- Governance:
+- Implementation stories:

package/src/dew-skills/3-solutioning/dew-data-architecture/assets/architecture-pattern-rubric.md

@@ -0,0 +1,104 @@
+# Architecture Pattern Rubric
+
+## Local-first
+
+Use when:
+- project is learning/portfolio/internal prototype
+- data volume is small to medium
+- fast iteration matters
+- local DuckDB/Python/dbt style workflow is useful
+- cloud deployment can come later
+
+Pros:
+- fast feedback
+- low cost
+- easy experimentation
+- good for learning
+
+Cons:
+- not production-grade by default
+- limited built-in orchestration
+- may need migration path to cloud/lakehouse
+
+## Warehouse-first
+
+Use when:
+- structured analytics is the core use case
+- sources fit relational modeling
+- BI/dashboard is main serving layer
+- team prefers SQL-centric development
+
+Pros:
+- strong analytics patterns
+- mature governance and BI integration
+
+Cons:
+- less flexible for files/unstructured data
+- may be costly at scale
+- streaming and ML feature use cases may need extra components
+
+## Lakehouse
+
+Use when:
+- data includes files, semi-structured data, large datasets
+- bronze/silver/gold layering is needed
+- batch and scalable transformations are expected
+- future ML/AI workloads may appear
+
+Pros:
+- flexible storage
+- supports medallion patterns
+- scalable
+- good for mixed workloads
+
+Cons:
+- more architecture complexity
+- requires stronger governance
+- may be overkill for small learning projects
+
+## Hybrid
+
+Use when:
+- local-first development is desired
+- cloud/lakehouse or warehouse is target deployment
+- project needs fast iteration and production path
+
+Pros:
+- balances learning speed and deployment realism
+- supports local validation and cloud implementation
+
+Cons:
+- requires clear environment boundaries
+- more documentation needed
+- potential drift between local and cloud
+
+## Streaming-first
+
+Use when:
+- source is event-driven
+- low latency is required
+- data is unbounded
+- freshness requirement cannot be met by batch
+
+Pros:
+- low latency
+- event-native design
+
+Cons:
+- much more operational complexity
+- harder debugging/replay
+- not appropriate unless freshness requires it
+
+## Application-integrated
+
+Use when:
+- data product is embedded in a web/app workflow
+- serving layer is API or app feature
+- operational UX matters
+
+Pros:
+- directly useful to end users
+- supports action-oriented workflows
+
+Cons:
+- requires stronger API, auth, and product engineering discipline