sddx-workflow 0.9.0 → 0.9.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -1,5 +1,10 @@
|
|
|
1
1
|
# Requirements: <Feature Name>
|
|
2
2
|
|
|
3
|
+
> **Decisions and trade-offs only — no implementation.** Code snippets are allowed
|
|
4
|
+
> only when they reduce ambiguity (e.g. a function signature, an example input/output,
|
|
5
|
+
> a concrete error shape). If a snippet is doing anything more than that, it belongs
|
|
6
|
+
> in `2-plan.md`, not here.
|
|
7
|
+
|
|
3
8
|
## Status
|
|
4
9
|
|
|
5
10
|
- [ ] Draft
|
|
@@ -70,6 +75,24 @@ Scenario: <add one scenario per distinct behavior>
|
|
|
70
75
|
Business: "Must ship before the Q2 demo on May 15."
|
|
71
76
|
UX: "Must match the existing row layout in the info modal — no redesign." -->
|
|
72
77
|
|
|
78
|
+
## Assumptions
|
|
79
|
+
|
|
80
|
+
<!-- What this document is taking as given about users, business rules, or scope.
|
|
81
|
+
Different from Constraints (hard rules from outside) and Open Questions (unresolved).
|
|
82
|
+
Each assumption must be **falsifiable** — something the reader could correct.
|
|
83
|
+
Generic filler ("users want a good experience") is not an assumption.
|
|
84
|
+
|
|
85
|
+
Format: what + why we're assuming it + what changes if it's wrong.
|
|
86
|
+
|
|
87
|
+
Example:
|
|
88
|
+
1. **Users only need the most recent open timestamp, not a history.** — based on
|
|
89
|
+
the original feature request; nobody asked for history.
|
|
90
|
+
If wrong: the data model needs an access_log table, not a single column.
|
|
91
|
+
|
|
92
|
+
2. **"Opening" means clicking into the file viewer, not previewing in a list.** —
|
|
93
|
+
list previews are passive, not deliberate access.
|
|
94
|
+
If wrong: the trigger surface expands and we'd record many more events. -->
|
|
95
|
+
|
|
73
96
|
## Open Questions
|
|
74
97
|
|
|
75
98
|
<!-- Mark each question by whether it blocks planning or can be decided during it.
|
package/templates/workflow.md
CHANGED
|
@@ -101,10 +101,10 @@ Rules:
|
|
|
101
101
|
**Purpose:** Lightweight flow for confirmed bugs.
|
|
102
102
|
|
|
103
103
|
Stages (in order, no skipping):
|
|
104
|
-
1. **Reproduce** —
|
|
105
|
-
2. **Diagnose** — identify root cause, not
|
|
106
|
-
3. **Fix** —
|
|
107
|
-
4. **Validate** —
|
|
104
|
+
1. **Reproduce** — if the repo has a test suite, write a failing test that captures the bug before doing anything else. If no suite exists or a test is not feasible, document a deterministic minimal repro (exact steps, inputs, observed vs. expected output) and state explicitly why a test isn't viable. If the bug cannot be reproduced at all, STOP and report — do not guess at a fix.
|
|
105
|
+
2. **Diagnose** — identify the root cause, not the symptom. State the root cause in one sentence before proposing any fix. If you cannot, run /assume and surface what's missing.
|
|
106
|
+
3. **Fix** — the minimum change that addresses the stated root cause. Do not refactor surrounding code, rename adjacent symbols, tidy formatting, or fix unrelated issues you notice along the way (note them, don't fix them).
|
|
107
|
+
4. **Validate** — the failing test from Reproduce now passes, and the full suite is green. If Reproduce used a manual repro, walk it again and confirm the original symptom is gone.
|
|
108
108
|
|
|
109
109
|
Stop points:
|
|
110
110
|
- After Reproduce: if unable to reproduce, STOP and report
|