waypoint-codex 1.0.15 → 1.0.16
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
|
@@ -144,6 +144,7 @@ Add these only when the work actually needs them:
|
|
|
144
144
|
- **Cleanup expectations**: Required when the implementation must delete replaced paths before the work is complete.
|
|
145
145
|
- **Test cases**: Required for behavioral changes where concrete input -> expected output examples prevent ambiguity.
|
|
146
146
|
- **Docs/workspace updates**: Required when the change affects durable project behavior or operator-facing guidance.
|
|
147
|
+
Any new or updated routable doc under `.waypoint/docs/` or `.waypoint/plans/` must include `summary`, `last_updated`, and `read_when` frontmatter so `DOCS_INDEX` can route it.
|
|
147
148
|
|
|
148
149
|
### Reduced-Depth Exception Rule
|
|
149
150
|
|
|
@@ -37,6 +37,7 @@ Once the user approves a plan or tells you to proceed, that approved scope is th
|
|
|
37
37
|
|
|
38
38
|
`WORKSPACE.md` is the live state file. `ACTIVE_PLANS.md` is the active execution checklist. Keep them current when state, blockers, or verification materially change.
|
|
39
39
|
When durable behavior changes, update the relevant docs during the work. When live execution state changes, update `WORKSPACE.md` or `ACTIVE_PLANS.md` during the work, not only at the end.
|
|
40
|
+
When creating or updating routable docs in `.waypoint/docs/` or `.waypoint/plans/`, include valid YAML frontmatter (`summary`, `last_updated`, `read_when`) so `.waypoint/DOCS_INDEX.md` can parse and route them.
|
|
40
41
|
|
|
41
42
|
When changing code, do not hesitate to aggressively delete legacy code and rebuild the system when that is the clearest path to accomplishing the goal. Prefer clean replacement over compatibility scaffolding unless the user or project docs explicitly require coexistence.
|
|
42
43
|
Do not widen a local change into a broader rewrite unless the current structure directly blocks the approved change or the user approves the expansion.
|