From 6d8ea11d3e30a64f0bdd9ceb91f592815d23ddf9 Mon Sep 17 00:00:00 2001 From: Joel Sahleen Date: Sun, 19 Jul 2026 20:47:33 -0600 Subject: [PATCH] process: document publish gate and scaffold wiring Capture retrospective learnings from issue #15: verify sibling npm tarballs include dist/ before bumping, and allow wiring stubs into real call sites during Phase 3 scaffold. Refs #15 Co-authored-by: Cursor --- project/process.md | 9 ++++++--- project/rules.md | 9 +++++++++ 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/project/process.md b/project/process.md index 4aa078c..2607f36 100644 --- a/project/process.md +++ b/project/process.md @@ -56,10 +56,13 @@ keep momentum on the lightweight track. 4. Stub out command class properties (`description`, `flags`, `args`, `run`) and helper function signatures, defining input and output types. 5. Create failing unit tests in the appropriate files under `src/tests/`. -6. Briefly explain the scaffolding and tests to the user and ask for feedback. -7. Commit the scaffolding in small, coherent commits prefixed with `scaffold:` +6. Wire stub helpers into real call sites (e.g. export/import command paths) + when needed so integration tests fail for the right reason — not only unit + tests against isolated stubs. +7. Briefly explain the scaffolding and tests to the user and ask for feedback. +8. Commit the scaffolding in small, coherent commits prefixed with `scaffold:` (see `project/rules.md`). -8. Push the branch and open a **draft pull request** whose title follows +9. Push the branch and open a **draft pull request** whose title follows Conventional Commits, so CI runs from here on. **[approval]** ### 4. Iteratively implement code until all unit tests pass. diff --git a/project/rules.md b/project/rules.md index 5395e64..2838ea1 100644 --- a/project/rules.md +++ b/project/rules.md @@ -93,6 +93,15 @@ traceability through the phases instead. - Meta-changes to `project/process.md` or `project/rules.md` belong in a separate PR from feature work. +## Dependencies + +When bumping `@worldware/msg` or other sibling packages, verify the published +npm tarball includes `dist/` before relying on it — e.g. +`npm pack @worldware/pkg@version --dry-run` and confirm dist files are listed. +Sibling repos now run `"prepack": "npm run build"` so pack/publish always +produces build output (msg-cli: PR #21; `@worldware/msg`: worldware-studios/msg#46, +after v0.8.0 shipped without `dist/`). + ## Failure handling - If tests cannot be made to pass, or the chosen approach proves wrong