@izkac/forgekit 0.3.3 → 0.3.5

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,6 +1,6 @@
1
1
  {
2
2
  "name": "@izkac/forgekit",
3
- "version": "0.3.3",
3
+ "version": "0.3.5",
4
4
  "description": "Forgekit CLIs — forgekit (install), forge (workflow), review (code review)",
5
5
  "type": "module",
6
6
  "bin": {
@@ -25,8 +25,11 @@ forge brief stamp # records specs hash + opens it in the operator's brows
25
25
  forge phase implement --tasks-total <N> # hard-gated on a fresh stamped brief
26
26
  ```
27
27
 
28
- If any spec file changes later, the brief goes **stale** — update the affected
29
- sections and `forge brief stamp` again. `forge brief check` reports status.
28
+ If any spec file changes later, the brief goes **stale** — the gate cannot
29
+ tell meaning changes from typo fixes, so it flags both. Triage cheaply: if the
30
+ edit doesn't change what the operator approved (typo, task renumber,
31
+ formatting), just re-run `forge brief stamp` — no rewrite. If it does, update
32
+ the affected sections first, then stamp. `forge brief check` reports status.
30
33
  Genuine edge case (operator explicitly waives it):
31
34
  `forge phase implement --allow-incomplete "<reason>"`.
32
35
 
@@ -80,6 +80,35 @@ driven by any command (e.g. requires a physical device). Reviewers police the
80
80
  reason; "no time" or "covered by unit tests" is a REJECT. Keep a short loop
81
81
  narrative under `## Product loop` in `verify-evidence.md` as reviewer context.
82
82
 
83
+ ### Keeping the loop cheap (cost policy)
84
+
85
+ "Too complex to test" is usually a signal to test it, not to wave it through —
86
+ a loop is complex exactly when the feature has many wiring seams, which is
87
+ when wiring silently breaks. Never skip the loop for complexity; control its
88
+ cost instead:
89
+
90
+ - **Ask before building complex harness infrastructure — and only then.**
91
+ The ask-line is infrastructure: a rig built from scratch, new
92
+ servers/containers/services, third-party accounts or sandboxes (e.g. real
93
+ payment checkout), device farms. That is a project, not a test — stop and
94
+ ask the user. **Everything below that line never needs permission**: if a
95
+ harness already exists (test server, isolated ports, scratch DB), author
96
+ the loop; writing fixtures, seed data, helper scripts, or extra steps
97
+ inside the existing rig is normal test work — just do it. Asking for
98
+ fixture-level work is over-asking; skipping the loop because the rig is
99
+ missing is under-testing — the ask is exactly the moment the operator can
100
+ say "build it once" and make every future loop on the project cheap.
101
+ - **One executed loop per capability, not per assertion.** Push edge cases
102
+ into unit tests; e2e proves the wiring exists.
103
+ - **Set `timeoutMs` from the step count up front.** A 10-step loop is never a
104
+ 30s test — a too-small budget fails at whatever line the clock runs out on,
105
+ which reads as a phantom regression.
106
+ - **Run it once, at the end, serially** — never alongside unit suites; load
107
+ makes real assertions look flaky.
108
+ - **Prefer a production/preview build over the dev server** when the loop
109
+ drives a web app — compile-on-demand and dev-mode socket noise dominate the
110
+ per-run cost and bury the actual assertion.
111
+
83
112
  ## 6. Job-kind closure
84
113
 
85
114
  Every job kind / entry point on the product surface (enums, API, UI) is, before