@boopkit/cap-product-design 0.6.10 → 0.6.11
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
|
@@ -39,7 +39,7 @@ For UI features, the same principle applies one level deeper: the hardest part i
|
|
|
39
39
|
- **Alternatives section earns trust** — showing what you rejected (and why) is what separates a design from a description
|
|
40
40
|
- **Details should be selective** — document the tricky parts and link to the rest; don't rewrite the code in prose
|
|
41
41
|
- **Prefer grounded terminology** — name things with generally-accepted software-engineering and product terms, and reuse the codebase's own names for things that already exist; avoid coined metaphors and vague shorthand ("the spine," "the gate," "the fix"). A design doc full of private labels costs every reader a translation pass. See `boop-writing-technical-prose` (anti-pattern 13).
|
|
42
|
-
- **Design docs live in `specs/`** — see
|
|
42
|
+
- **Design docs live in `specs/`** — see `boop-project-mgmt-engineering-planning` for how designs become work plans
|
|
43
43
|
|
|
44
44
|
## For refactor specs: audit current state first
|
|
45
45
|
|