@massu/core 1.15.4 → 1.15.6
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/CHANGELOG.md
CHANGED
|
@@ -10,6 +10,89 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
|
|
|
10
10
|
> redistributed under the **Apache License 2.0**. Full license + NOTICE:
|
|
11
11
|
> `packages/core/assets/embedder/MODEL-LICENSE`.
|
|
12
12
|
|
|
13
|
+
## [1.15.6] - 2026-07-14
|
|
14
|
+
|
|
15
|
+
### Fixed — the golden path's Deep Security Audit phase was missing entirely
|
|
16
|
+
|
|
17
|
+
`references/phase-3.5-security-audit.md` — a full adversarial security audit loop over every file
|
|
18
|
+
changed in a golden-path run (parallel red-team agents, iterating until the audit converges to ZERO
|
|
19
|
+
findings). Its own text: *"This phase is NEVER skipped. Security is non-negotiable regardless of
|
|
20
|
+
change size, type, or scope."*
|
|
21
|
+
|
|
22
|
+
0.6.1 SHIPS phase-3.5-security-audit.md
|
|
23
|
+
1.0.0 does NOT ship it
|
|
24
|
+
1.15.5 does NOT ship it
|
|
25
|
+
|
|
26
|
+
**It exists in no commit in massu's history** — no deletion commit, no changelog entry, no trace.
|
|
27
|
+
From v1.0.0 through v1.15.5, every user's golden path ran with **no security audit phase at all**.
|
|
28
|
+
The only surviving copy was in a consumer repo that had committed its installed commands months ago.
|
|
29
|
+
|
|
30
|
+
Restored, wired as **Phase 3.5** (after simplification, before pre-commit, exactly where its own
|
|
31
|
+
spec says it belongs), and added to the reference table.
|
|
32
|
+
|
|
33
|
+
**Why every guard missed it, and what changed:** the reference-link check asks *"does every
|
|
34
|
+
reference file have a link?"* — and a file DELETED OUTRIGHT has no link to be missing. A check that
|
|
35
|
+
only sees BROKEN things is structurally blind to ABSENT ones. The anti-vacuity suite now asserts,
|
|
36
|
+
per subsystem, that the file **EXISTS** *and* is **LINKED** *and* is **INVOKED** — a conjunction no
|
|
37
|
+
deletion can satisfy. Proven by attack: deleting the spec file goes RED; deleting the phase while
|
|
38
|
+
keeping the file goes RED.
|
|
39
|
+
|
|
40
|
+
This is the fifth quality subsystem found missing from the golden path in one day, and the only one
|
|
41
|
+
deleted so completely it left no evidence anywhere in the repository.
|
|
42
|
+
|
|
43
|
+
## [1.15.5] - 2026-07-14
|
|
44
|
+
|
|
45
|
+
### Fixed — CRITICAL: `install-commands` could destroy your customizations
|
|
46
|
+
|
|
47
|
+
- **The installer recorded a hash for a file it did not write.** On meeting a command file with no
|
|
48
|
+
manifest entry, it kept the file (correct) and then recorded THAT FILE'S hash into the manifest —
|
|
49
|
+
a manifest whose entire meaning is "this is the hash of what massu installed". On the next run the
|
|
50
|
+
safe-upgrade path read that back, concluded the file was untouched, and **overwrote it**.
|
|
51
|
+
**Run 1 armed it; run 2 destroyed the work.** Measured against a real repo: 36 files of local
|
|
52
|
+
customization deleted on the second install, reported as success.
|
|
53
|
+
|
|
54
|
+
It now records **nothing** when it cannot prove authorship. The ambiguity is re-detected on every
|
|
55
|
+
run and the file is kept on every run. A customized file with no provenance now FREEZES: safe, but
|
|
56
|
+
stale. Upstream changes reach it via an explicit `rm <file> && massu install-commands`, or a future
|
|
57
|
+
three-way merge. Between "stale" and "your work is silently deleted", we choose stale.
|
|
58
|
+
|
|
59
|
+
- **A test was protecting the bug.** `MANIFEST-06` asserted the fail-open as correct behaviour
|
|
60
|
+
("Manifest seeded with EXISTING hash for kept"). The test agreed with the code because both were
|
|
61
|
+
written from the same wrong assumption. Assertion inverted.
|
|
62
|
+
|
|
63
|
+
- **`scripts/quarantine-poisoned-manifest.mjs`** — repairs a manifest that already contains such a
|
|
64
|
+
hash. It does not re-derive what massu "would have written" (the installer resolves variants and
|
|
65
|
+
renders templates, so the installed bytes are a function of the repo's config); it runs the REAL
|
|
66
|
+
installer against a scratch copy and drops any entry that authorises an overwrite. Dry run by
|
|
67
|
+
default; backs the manifest up before writing.
|
|
68
|
+
|
|
69
|
+
### Fixed — the golden path was missing the machinery that checks the work
|
|
70
|
+
|
|
71
|
+
`8fff05d`, whose message announced only additions, silently **deleted** three quality subsystems.
|
|
72
|
+
The spec files kept shipping; nothing invoked them. Restored and re-wired:
|
|
73
|
+
|
|
74
|
+
- **Sprint contracts (2A.5)** — agree definition-of-done per item BEFORE implementing it.
|
|
75
|
+
- **QA evaluator (2C)** — adversarial acceptance testing AGAINST those contracts.
|
|
76
|
+
- **VR-VISUAL** — weighted 4-dimension scoring (threshold >= 3.0).
|
|
77
|
+
- **Gap analyzer's 7th category** — sprint-contract compliance. Without it the loop could report
|
|
78
|
+
zero gaps while the work missed the definition of done it was built against.
|
|
79
|
+
|
|
80
|
+
And a fourth that was **never wired at all**: **Phase 5.5 — Production Verification**, shipped in
|
|
81
|
+
v0.6.0 and invoked by nothing for its entire life. Its own first line reads *"A feature is NOT
|
|
82
|
+
complete until it is verified working in production with real data. 'Deployed' and 'working' are two
|
|
83
|
+
completely different things."*
|
|
84
|
+
|
|
85
|
+
- **A new gate that deletion cannot satisfy.** The previous check asked only "does every reference
|
|
86
|
+
file have a link?" — so deleting the spec files made it pass. The new one asserts, per subsystem,
|
|
87
|
+
that the file EXISTS **and** is LINKED **and** is INVOKED by name. Proven by attacking all three.
|
|
88
|
+
|
|
89
|
+
### Fixed
|
|
90
|
+
- `massu-pattern-scanner.sh` Check 40 used a relative path and silently failed from any directory but
|
|
91
|
+
the repo root — including `packages/core/`, which is where npm runs `prepublishOnly`. The
|
|
92
|
+
pre-publish check that runs it had therefore never worked.
|
|
93
|
+
- `diff-commands-vs-docs.sh` derived its repo root via `git rev-parse || pwd`; outside a git tree the
|
|
94
|
+
fallback turned "I cannot find the repo" into a confident wrong answer.
|
|
95
|
+
|
|
13
96
|
## [1.15.4] - 2026-07-13
|
|
14
97
|
|
|
15
98
|
### Security
|
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
# Phase 3.5: Deep Security Audit
|
|
2
|
+
|
|
3
|
+
> Reference doc for `/massu-golden-path`. Return to main file for overview.
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
[GOLDEN PATH -- PHASE 3.5: DEEP SECURITY AUDIT]
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
## Purpose
|
|
10
|
+
|
|
11
|
+
Run a full adversarial security audit loop against ALL files changed in this golden path run. This is a deep, iterative audit with parallel red-team agents that converges to zero findings. It runs AFTER simplification (Phase 3) so the audit targets the final, cleaned-up code -- and BEFORE pre-commit verification (Phase 4) so all security fixes are included in the verification gates.
|
|
12
|
+
|
|
13
|
+
**This phase is NEVER skipped.** Security is non-negotiable regardless of change size, type, or scope.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## 3.5.1 Determine Audit Scope
|
|
18
|
+
|
|
19
|
+
Collect ALL files changed during this golden path run:
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
git diff --name-only HEAD
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
If files were already committed in earlier phases, also include:
|
|
26
|
+
```bash
|
|
27
|
+
git diff --name-only main...HEAD
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
The audit scope is the union of all changed files. Do NOT narrow scope -- every changed file gets audited.
|
|
31
|
+
|
|
32
|
+
**Output:**
|
|
33
|
+
```
|
|
34
|
+
SECURITY AUDIT SCOPE:
|
|
35
|
+
Files: [N]
|
|
36
|
+
[list of files]
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## 3.5.2 Execute Deep Security Audit
|
|
42
|
+
|
|
43
|
+
Run the full security audit protocol against the scoped files:
|
|
44
|
+
|
|
45
|
+
1. **Launch 2-4 parallel adversarial reviewer agents** adapted to the codebase area:
|
|
46
|
+
- Backend/API code: 4 agents (Injection, Network/Leakage, DoS/Resources, Red Team Bypass)
|
|
47
|
+
- Frontend code: 3 agents (XSS/Injection, Auth/Data Exposure, Input Validation/Logic)
|
|
48
|
+
- Infrastructure/config: 2 agents (Secrets/Config, Dependencies/Supply Chain)
|
|
49
|
+
|
|
50
|
+
2. **Consolidate findings** -- deduplicate across agents, take higher severity on disagreements
|
|
51
|
+
|
|
52
|
+
3. **Fix ALL findings** -- CRITICAL first, then HIGH, MEDIUM, LOW. INFO documented only.
|
|
53
|
+
|
|
54
|
+
4. **Verify fixes** -- import checks, input validation tests, functionality preserved
|
|
55
|
+
|
|
56
|
+
5. **Loop until zero findings** -- max 5 iterations, escalate to user if still failing after 5
|
|
57
|
+
|
|
58
|
+
---
|
|
59
|
+
|
|
60
|
+
## 3.5.3 Attack Vector Coverage
|
|
61
|
+
|
|
62
|
+
Every audit iteration MUST verify the complete attack vector checklist:
|
|
63
|
+
|
|
64
|
+
### Universal
|
|
65
|
+
- Hardcoded secrets / API keys / credentials
|
|
66
|
+
- Error messages leaking internal details
|
|
67
|
+
- Dependency vulnerabilities
|
|
68
|
+
- Input validation on ALL external boundaries
|
|
69
|
+
|
|
70
|
+
### Backend / API
|
|
71
|
+
- SQL injection, command injection, path traversal
|
|
72
|
+
- SSRF, authentication bypass, authorization bypass
|
|
73
|
+
- DoS via unbounded inputs, memory leaks, race conditions
|
|
74
|
+
- Response validation, type confusion
|
|
75
|
+
|
|
76
|
+
### Frontend
|
|
77
|
+
- XSS, open redirects, sensitive data in client state
|
|
78
|
+
- CSRF, client-side auth bypass
|
|
79
|
+
|
|
80
|
+
### LLM / AI Specific
|
|
81
|
+
- Prompt injection, model output trust
|
|
82
|
+
- Tool argument injection, vision/multimodal injection
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## 3.5.4 Completion Gate
|
|
87
|
+
|
|
88
|
+
The phase completes ONLY when the audit loop achieves a clean pass with zero findings.
|
|
89
|
+
|
|
90
|
+
```
|
|
91
|
+
SECURITY_AUDIT_GATE: PASS
|
|
92
|
+
Iterations: [N]
|
|
93
|
+
Total findings fixed: [N]
|
|
94
|
+
Breakdown: [X] CRITICAL, [X] HIGH, [X] MEDIUM, [X] LOW fixed
|
|
95
|
+
Clean pass: Iteration [N]
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
**Do NOT proceed to Phase 4 until SECURITY_AUDIT_GATE = PASS.**
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## Rules
|
|
103
|
+
|
|
104
|
+
1. **NEVER skip this phase** -- not for small changes, not for docs, not for config
|
|
105
|
+
2. **NEVER proceed with findings unfixed** -- zero means zero
|
|
106
|
+
3. **ALL severity levels get fixed** -- CRITICAL through LOW
|
|
107
|
+
4. **No commit prompt** -- unlike standalone security audit commands, do NOT offer to commit here (Phase 4 handles commits)
|
|
108
|
+
5. **Findings feed Phase 4** -- security fixes are verified by Phase 4's type check, build, lint, and secrets gates automatically
|
|
@@ -106,15 +106,25 @@ Read `references/phase-1-plan-creation.md` for full details.
|
|
|
106
106
|
|
|
107
107
|
Read `references/phase-2-implementation.md` for full details.
|
|
108
108
|
|
|
109
|
-
**Summary**:
|
|
109
|
+
**Summary**: Eight sub-phases:
|
|
110
110
|
- **2A**: Extract plan items into tracking table, initialize session state
|
|
111
|
+
- **2A.5**: **Sprint contracts** — negotiate definition-of-done per plan item BEFORE implementing it (scope boundary, acceptance criteria, VR-* mapping). See `references/sprint-contract-protocol.md`
|
|
111
112
|
- **2B**: Implementation loop (pre-check, execute, guardrail, verify, update per item)
|
|
112
|
-
- **2C**: Multi-perspective review (3 parallel agents: security, architecture, quality)
|
|
113
|
-
- **2D**: Verification audit loop (subagent, circuit breaker CR-37, max 10 iterations)
|
|
113
|
+
- **2C**: Multi-perspective review (3 parallel agents: security, architecture, quality) + **QA evaluator** (conditional, UI plans only — adversarial Playwright-based acceptance testing **against the sprint contracts agreed in 2A.5**). See `references/qa-evaluator-spec.md`
|
|
114
|
+
- **2D**: Verification audit loop (subagent, circuit breaker CR-37, sprint-contract verification, max 10 iterations)
|
|
114
115
|
- **2E**: Post-build reflection + memory persist (CR-38)
|
|
115
116
|
- **2F**: Documentation sync (if user-facing features)
|
|
116
117
|
- **2G**: Browser verification & fix loop (auto-triggers if UI files changed, Playwright MCP)
|
|
117
118
|
|
|
119
|
+
> **2A.5 and 2C are load-bearing, and they were missing.** Commit `8fff05d` — whose message
|
|
120
|
+
> announced only ADDITIONS ("CR-45 zero-tolerance mandate") — silently deleted the sprint
|
|
121
|
+
> contracts and the QA evaluator from this file. Every golden-path run since has implemented
|
|
122
|
+
> against no agreed definition of done, and accepted its own work without an adversarial check.
|
|
123
|
+
> The spec files never stopped shipping; nothing invoked them. Restored 2026-07-14.
|
|
124
|
+
>
|
|
125
|
+
> The order matters: **2A.5 agrees what "done" means BEFORE 2B builds it, so 2C has something
|
|
126
|
+
> to judge against.** A QA evaluator with no contract is grading an exam with no answer key.
|
|
127
|
+
|
|
118
128
|
**Gate**: APPROVAL POINT #2: NEW PATTERN (if needed, any sub-phase)
|
|
119
129
|
|
|
120
130
|
---
|
|
@@ -123,7 +133,12 @@ Read `references/phase-2-implementation.md` for full details.
|
|
|
123
133
|
|
|
124
134
|
Read `references/phase-2.5-gap-analyzer.md` for full details.
|
|
125
135
|
|
|
126
|
-
**Summary**: After implementation completes, run a continuous gap and enhancement analysis loop. A subagent analyzes all changed files across
|
|
136
|
+
**Summary**: After implementation completes, run a continuous gap and enhancement analysis loop. A subagent analyzes all changed files across **7 categories** (functional gaps, UX gaps, data integrity, security, pattern compliance, enhancements, **sprint-contract compliance**). **VR-VISUAL uses weighted 4-dimension scoring (threshold >= 3.0)** — see `references/vr-visual-calibration.md` for the 5/3/1 calibration examples. Every gap/enhancement found is fixed immediately. The loop re-runs until a full pass discovers ZERO gaps. Max 10 iterations. Skippable only for documentation-only changes or explicit user request.
|
|
137
|
+
|
|
138
|
+
> **The 7th category and VR-VISUAL's scoring were deleted by `8fff05d` and restored 2026-07-14.**
|
|
139
|
+
> Without the sprint-contract category, the loop could report ZERO gaps while the work missed the
|
|
140
|
+
> definition of done it was built against. Without the weighted scoring, VR-VISUAL was a
|
|
141
|
+
> pass/fail vibe check with a calibration file nobody read.
|
|
127
142
|
|
|
128
143
|
---
|
|
129
144
|
|
|
@@ -135,6 +150,35 @@ Read `references/phase-3-simplify.md` for full details.
|
|
|
135
150
|
|
|
136
151
|
---
|
|
137
152
|
|
|
153
|
+
## PHASE 3.5: DEEP SECURITY AUDIT
|
|
154
|
+
|
|
155
|
+
Read `references/phase-3.5-security-audit.md` for full details.
|
|
156
|
+
|
|
157
|
+
**Summary**: A full adversarial security audit loop against EVERY file changed in this run —
|
|
158
|
+
parallel red-team agents, iterating until the audit converges to ZERO findings. It runs AFTER
|
|
159
|
+
simplification (so it audits the final, cleaned-up code) and BEFORE pre-commit verification (so
|
|
160
|
+
every security fix is caught by the Phase 4 gates).
|
|
161
|
+
|
|
162
|
+
**THIS PHASE IS NEVER SKIPPED.** Security is non-negotiable regardless of the size, type, or scope
|
|
163
|
+
of the change. Do not narrow the audit scope: every changed file gets audited.
|
|
164
|
+
|
|
165
|
+
> **This phase SHIPPED in v0.6.1 and had vanished by v1.0.0.** It exists in no commit in this
|
|
166
|
+
> repository's history — the only surviving copy on the machine was in a consumer repo that had
|
|
167
|
+
> committed its installed commands back in April. So for every version from v1.0.0 to v1.15.5,
|
|
168
|
+
> every user's golden path ran with **no security audit phase at all**, and nothing anywhere said
|
|
169
|
+
> so.
|
|
170
|
+
>
|
|
171
|
+
> It was found by accident, on 2026-07-14, when a `git status` showed the file being deleted from
|
|
172
|
+
> that consumer during a reinstall. **The reference-link guard could never have found it:** that
|
|
173
|
+
> guard asks "does every reference file have a link?", and a file that has been deleted outright
|
|
174
|
+
> has no link to be missing. A check that only sees *broken* things is blind to *absent* ones —
|
|
175
|
+
> which is the same failure as a scanner that reports CLEAN because it scanned zero files.
|
|
176
|
+
>
|
|
177
|
+
> Restored and wired 2026-07-14. Guarded by `golden-path-quality-subsystems-wired.test.ts`, which
|
|
178
|
+
> asserts the file EXISTS, is LINKED, and is INVOKED — a conjunction no deletion can satisfy.
|
|
179
|
+
|
|
180
|
+
---
|
|
181
|
+
|
|
138
182
|
## PHASE 4: PRE-COMMIT VERIFICATION
|
|
139
183
|
|
|
140
184
|
Read `references/phase-4-commit.md` for full details.
|
|
@@ -155,6 +199,30 @@ Read `references/phase-5-push.md` for full details.
|
|
|
155
199
|
|
|
156
200
|
---
|
|
157
201
|
|
|
202
|
+
## PHASE 5.5: PRODUCTION VERIFICATION
|
|
203
|
+
|
|
204
|
+
Read `references/phase-5.5-production-verify.md` for full details.
|
|
205
|
+
|
|
206
|
+
**Summary**: After push and CI success, verify the deployment actually LANDED and the feature
|
|
207
|
+
actually WORKS — against production, with real data. Confirm the deploy reached READY, read the
|
|
208
|
+
runtime logs for startup errors, then exercise the feature itself and read back what the system
|
|
209
|
+
returns. Skippable ONLY when the change has no deployed surface (docs-only, tooling-only).
|
|
210
|
+
|
|
211
|
+
**Core principle**: *A feature is NOT complete until it is verified working in production with real
|
|
212
|
+
data. "Deployed" and "working" are two completely different things.*
|
|
213
|
+
|
|
214
|
+
> **This phase was written, shipped in v0.6.0 — and NEVER WIRED IN.** It has been sitting in
|
|
215
|
+
> `references/` for its entire life with nothing invoking it: a `git log -S` over this file finds
|
|
216
|
+
> no commit that ever linked it. It was not deleted; it was never enabled. That is its own failure
|
|
217
|
+
> class ("hunt the built-and-never-enabled"), and it is the more embarrassing one, because the
|
|
218
|
+
> phase that would have caught "we shipped it but never checked it worked" was itself shipped and
|
|
219
|
+
> never checked. Wired 2026-07-14.
|
|
220
|
+
>
|
|
221
|
+
> It goes AFTER the push (you cannot verify a deployment that has not happened) and BEFORE
|
|
222
|
+
> completion (you may not call it done until the world agrees it is).
|
|
223
|
+
|
|
224
|
+
---
|
|
225
|
+
|
|
158
226
|
## PHASE 6: COMPLETION
|
|
159
227
|
|
|
160
228
|
Read `references/phase-6-completion.md` for full details.
|
|
@@ -171,12 +239,17 @@ This skill is a folder. The following files are available for reference:
|
|
|
171
239
|
|------|---------|-----------|
|
|
172
240
|
| `references/phase-0-requirements.md` | Requirements interview, ambiguity detection, 10-dimension coverage map | Starting a new implementation from a task description |
|
|
173
241
|
| `references/phase-1-plan-creation.md` | Config/schema reality check, blast radius analysis, plan generation, audit loop | Writing or auditing a plan |
|
|
174
|
-
| `references/phase-2-implementation.md` | Item loop, multi-perspective review, verification audit, browser testing | Executing implementation; any Phase 2 sub-phase |
|
|
175
|
-
| `references/
|
|
242
|
+
| `references/phase-2-implementation.md` | Item loop, sprint contracts, multi-perspective review, QA evaluator, verification audit, browser testing | Executing implementation; any Phase 2 sub-phase |
|
|
243
|
+
| `references/sprint-contract-protocol.md` | Sprint contract template, quality bar, negotiation rules, skip conditions | Phase 2A.5 — agreeing definition-of-done before implementing |
|
|
244
|
+
| `references/qa-evaluator-spec.md` | Adversarial QA evaluator: 4 dimensions, anti-leniency rules, known failure patterns | Phase 2C — QA evaluation (UI plans only) |
|
|
245
|
+
| `references/vr-visual-calibration.md` | Score 5/3/1 calibration examples for VR-VISUAL weighted dimensions | Calibrating VR-VISUAL scoring in Phase 2.5 |
|
|
246
|
+
| `references/phase-2.5-gap-analyzer.md` | Gap/enhancement analysis loop, 7 categories (incl. sprint-contract compliance), fix-and-repass until zero | After implementation, before simplification |
|
|
176
247
|
| `references/phase-3-simplify.md` | Pattern scanner fast gate, dead code detection, parallel semantic review agents | Running simplification after implementation |
|
|
248
|
+
| `references/phase-3.5-security-audit.md` | Adversarial red-team security audit loop over every changed file, iterating to ZERO findings | Phase 3.5 — after simplification, before pre-commit. NEVER skipped |
|
|
177
249
|
| `references/phase-4-commit.md` | Auto-verification gates, quality scoring, commit format | Preparing a commit |
|
|
178
250
|
| `references/phase-5-push.md` | Pre-flight, 4-tier push verification, regression detection | Preparing to push to remote |
|
|
179
|
-
| `references/phase-
|
|
251
|
+
| `references/phase-5.5-production-verify.md` | Deployment landed, runtime logs clean, feature exercised against production with real data | Phase 5.5 — after push, before calling it done |
|
|
252
|
+
| `references/phase-6-completion.md` | Final report, plan status update, auto-learning | After production verification; completing the golden path |
|
|
180
253
|
| `references/approval-points.md` | Exact format and options for all 4 approval points (5 with --competitive: Plan, New Pattern, Winner Selection, Commit, Push) | Presenting any approval gate to the user |
|
|
181
254
|
| `references/competitive-mode.md` | Competitive mode protocol: agent spawning, scoring, winner selection | Using --competitive flag |
|
|
182
255
|
| `references/error-handling.md` | Abort handling, non-recoverable errors, post-compaction re-verification, competitive mode errors | On user abort, blocker error, or after context compaction |
|
package/dist/cli.js
CHANGED
|
@@ -4357,9 +4357,9 @@ function syncDirectory(sourceDir, targetDir, framework, manifest, manifestKeyPre
|
|
|
4357
4357
|
continue;
|
|
4358
4358
|
}
|
|
4359
4359
|
if (lastInstalledHash === void 0) {
|
|
4360
|
-
manifest.entries[manifestKey] = existingHash;
|
|
4361
4360
|
process.stderr.write(
|
|
4362
|
-
`First-install
|
|
4361
|
+
`First-install: keeping existing ${targetPath} (differs from upstream, and massu has no record of writing it).
|
|
4362
|
+
It will be kept on every future install until you resolve it explicitly.
|
|
4363
4363
|
To accept upstream: rm ${targetPath} && npx massu install-commands
|
|
4364
4364
|
`
|
|
4365
4365
|
);
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@massu/core",
|
|
3
|
-
"version": "1.15.
|
|
3
|
+
"version": "1.15.6",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "AI Engineering Governance MCP Server - Session memory, knowledge system, feature registry, code intelligence, rule enforcement, tiered tooling (12 free / 73 total), 56 workflow commands, 11 agents, 20+ patterns",
|
|
6
6
|
"main": "./dist/cli.js",
|