Observation
package.json pins two @git-stunts packages to exact versions while the rest of the ecosystem uses caret ranges:
| Package |
Think declares |
Sibling packages declare |
npm latest |
@git-stunts/plumbing |
3.0.3 (exact) |
git-warp/git-cas: ^3.1.0 |
3.2.0 |
@git-stunts/git-cas |
6.0.0 (exact) |
git-warp: ^6.2.0 |
— |
@git-stunts/git-warp |
^18.2.1 |
— |
19.0.2 |
Why this is bad
An exact pin means an upstream fix can never reach Think by semver — it requires a hand edit that nothing prompts.
This is live right now. git-stunts/plumbing#13 fixes a defect where git could not read the operator's ~/.gitconfig, causing every mind commit to be attributed to a fabricated user@hostname address that no forge can verify. git-warp and git-cas will pick that fix up automatically once published, because ^3.1.0 already admits it. Think will not, and the copy Think pins is the one that matters: Think calls ShellRunnerFactory.create() from its own @git-stunts/plumbing and hands that runner to git-warp, so git-warp's nested copy is not the deciding one.
Verified by patching node_modules/@git-stunts/plumbing in place: captures then commit as the configured identity. Restored, they revert to the fabricated address.
The pins also disagree with the ecosystem in a way that will collide. Think wants git-warp ^18.2.1 while npm latest is 19.0.2 and PR #29 is mid-cutover to v19; Think pins git-cas 6.0.0 while git-warp itself wants ^6.2.0. The v19 cutover and the identity-fix propagation both need to edit these same pins, so running them concurrently risks conflicting changes across #29 and #34.
Suggested direction
- Decide deliberately whether exact pins are policy. If they are, the reason should be documented next to them, and a cadence should exist for reviewing them —
docs/method/backlog/bad-code/CORE_audit-no-dependency-freshness-cadence.md already notes the missing cadence.
- If they are incidental, move to caret ranges consistent with the sibling packages and rely on the lockfile for reproducibility.
- Either way, sequence the v19 cutover and the identity propagation rather than interleaving them.
References
Observation
package.jsonpins two@git-stuntspackages to exact versions while the rest of the ecosystem uses caret ranges:@git-stunts/plumbing3.0.3(exact)git-warp/git-cas:^3.1.0@git-stunts/git-cas6.0.0(exact)git-warp:^6.2.0@git-stunts/git-warp^18.2.1Why this is bad
An exact pin means an upstream fix can never reach Think by semver — it requires a hand edit that nothing prompts.
This is live right now.
git-stunts/plumbing#13fixes a defect where git could not read the operator's~/.gitconfig, causing every mind commit to be attributed to a fabricateduser@hostnameaddress that no forge can verify.git-warpandgit-caswill pick that fix up automatically once published, because^3.1.0already admits it. Think will not, and the copy Think pins is the one that matters: Think callsShellRunnerFactory.create()from its own@git-stunts/plumbingand hands that runner to git-warp, so git-warp's nested copy is not the deciding one.Verified by patching
node_modules/@git-stunts/plumbingin place: captures then commit as the configured identity. Restored, they revert to the fabricated address.The pins also disagree with the ecosystem in a way that will collide. Think wants
git-warp ^18.2.1while npm latest is 19.0.2 and PR #29 is mid-cutover to v19; Think pinsgit-cas 6.0.0while git-warp itself wants^6.2.0. The v19 cutover and the identity-fix propagation both need to edit these same pins, so running them concurrently risks conflicting changes across #29 and #34.Suggested direction
docs/method/backlog/bad-code/CORE_audit-no-dependency-freshness-cadence.mdalready notes the missing cadence.References
git-stunts/plumbing#13— the fix that cannot propagatedocs/method/backlog/bad-code/CORE_git-warp-dependency-truth.mddocs/method/backlog/bad-code/CORE_audit-no-dependency-freshness-cadence.md