@nusoft/nuos-build-catalogue 0.29.1 → 0.30.0

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": "@nusoft/nuos-build-catalogue",
3
- "version": "0.29.1",
3
+ "version": "0.30.0",
4
4
  "description": "NuOS build-catalogue tooling: semantic search (WU 110) + migration runner that lifts markdown artefacts into JSON-backed workflow records (WU 111, Phase G).",
5
5
  "type": "module",
6
6
  "bin": {
@@ -100,10 +100,42 @@ For each spawn:
100
100
 
101
101
  When each agent returns, capture their output. Three outcomes are typical:
102
102
 
103
- - **APPROVED** by reviewer → work unit is ready to promote ✅ shipped. Run end-of-session to commit.
103
+ - **APPROVED** by reviewer → do NOT promote yet. Go to Step 5.1 developer walkthrough.
104
104
  - **REQUEST CHANGES** by reviewer → re-spawn coder with reviewer's findings as input. Cap at 3 retry loops; if still failing, escalate to debugger or operator.
105
105
  - **ESCALATE** (any agent surfaces an architectural issue, a design ambiguity, a need for the operator's call) → STOP the swarm. Surface the issue to the operator in plain English; do not auto-decide.
106
106
 
107
+ ## Step 5.1 — Developer walkthrough (mandatory before promotion)
108
+
109
+ The reviewer has approved. Before the work unit is promoted to shipped, **stop and brief the developer** so they can verify the feature themselves in their running dev environment.
110
+
111
+ Write a short, plain-English walkthrough that tells the developer:
112
+
113
+ 1. **What was built** — one or two sentences describing the feature or change in terms of what it does, not how it was coded.
114
+ 2. **How to see it** — the exact steps to exercise the feature right now: which URL to open, which screen to navigate to, which action to take, which data to enter. Be specific enough that someone can follow without guessing.
115
+ 3. **What to look for** — what correct behaviour looks like at each step. What should appear, what should happen, what should NOT happen.
116
+ 4. **Any edge cases worth checking** — a second scenario or error path that is worth a quick manual check given what was built.
117
+
118
+ Example format:
119
+
120
+ ---
121
+ **What was built:** The password reset email now sends within 5 seconds and links to the new `/reset` page.
122
+
123
+ **How to test it:**
124
+ 1. Go to `/login` and click "Forgot password"
125
+ 2. Enter any registered email address and submit
126
+ 3. Check that email inbox — the reset email should arrive within 5 seconds
127
+ 4. Click the link in the email — it should open `/reset?token=…` and show the new password form
128
+
129
+ **What correct looks like:** The form accepts the new password, shows a confirmation message, and redirects to `/login`. The old password no longer works.
130
+
131
+ **Worth checking:** Try submitting the reset form twice — the second submission should show "link expired", not an error page.
132
+
133
+ ---
134
+
135
+ Then ask: **"Does everything look right? Reply 'yes' to promote this work unit, or tell me what you found and I'll route it back to the coder."**
136
+
137
+ **Do not promote, do not run end-of-session, do not move to Step 6 until the developer explicitly confirms.**
138
+
107
139
  ## Step 5.5 — Run the test gate (JS/TS projects)
108
140
 
109
141
  If `methodfile.json` has `testing.framework: "vitest"` and `testing.enforced: true`, this gate is mandatory before the reviewer's APPROVE can stand. The reviewer is responsible for running it (see [reviewer.md](../agents/reviewer.md)), but the coordinator owns the outcome.