Files

Tom Boucher 79002a00cb chore(#518 ): rename npm package + bin to @opengsd/gsd-core (#519 )

* chore: rename npm package + bin to @opengsd/gsd-core (functional)

- package.json: name @opengsd/get-shit-done-redux → @opengsd/gsd-core,
  bin key get-shit-done-redux → gsd-core, repository/homepage/bugs URLs
- package-lock.json: regenerated (npm install --package-lock-only)
- tests/**, scripts/**, bin/**, .github/**, agents/**, commands/**,
  get-shit-done/bin/**, get-shit-done/workflows/**:
  applied the 4-rule replacement (scoped npm ref, GitHub repo path,
  bin/clone invocations) per #505 single-source refactor

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: sweep live references to @opengsd/gsd-core

Update all live documentation (README.md + translations, docs/**,
CONTRIBUTING.md, VERSIONING.md, SECURITY.md, CONTEXT.md,
docs/CANARY.md) to reflect the renamed package and repository.

Rules applied:
- @opengsd/get-shit-done-redux → @opengsd/gsd-core (scoped npm name)
- open-gsd/get-shit-done-redux → open-gsd/gsd-core (GitHub repo)
- GSD-redux/get-shit-done-redux → open-gsd/gsd-core (stale badge org)
- bare bin/clone refs → gsd-core

CHANGELOG.md, docs/adr/**, docs/RELEASE-*.md, docs/research/**,
and .changeset/** are preserved byte-identical.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix: add negative lookbehind to slash-command regex in bug-2954 test

The extractSlashReferences regex matched /gsd-core inside npm package
URLs (@opengsd/gsd-core), producing a false /gsd:core command reference.
Adding a negative lookbehind (?<![a-z]) excludes matches preceded by a
letter, so only standalone /gsd-<cmd> and /gsd:<cmd> tokens are found.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* chore(#518): add changeset for package rename

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* test(#518): update package-identity expectations to the renamed coordinates

The rebase regenerated the seam to @opengsd/gsd-core (bin gsd-core, repo
open-gsd/gsd-core). The #498 seam tests assert deriveIdentity against the REAL
package.json, so their expected literals must follow the rename. The drift-lint
unit test is left as-is — its SEAM is a self-consistent fixture and its
stale-literal detection cases would shift if altered; the live-repo scan in it
already passes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

2026-05-30 17:25:02 -04:00

3.3 KiB

Raw Blame History

Canary Stream

The canary dist-tag is GSD's earliest preview channel. It exists so contributors and willing early adopters can exercise in-flight features against the long-lived dev integration branch before they have any expectation of stability.

Stream policy

GSD ships through three npm dist-tags, each fed by exactly one git branch. Streams do not mix.

Branch	dist-tag	Audience	Stability
`dev`	`canary`	Contributors, willing early adopters	Best-effort. May regress between cuts. Roll-forward only.
`main`	`next`	Maintainers, RC testers	Release-candidate quality. Bug-bar enforced.
`main`	`latest`	Everyone else	Production stable. The default `npm install` target.

dev is the integration branch for in-flight feature work (typically multi-PR vertical slices like the MVP/TDD/UAT track in 1.50.0). When the dev work stabilizes, it promotes to main as an RC train (vX.Y.Z-rc.N published to next), and after the RC train bakes, the same train promotes again to latest.

A canary build NEVER becomes a next build directly, and a next build NEVER becomes a latest build directly — every promotion goes through a fresh tag and a fresh release.

Installing canary

# One-off invocation (npx)
npx @opengsd/gsd-core@canary

# Pin to the canary dist-tag globally
npm install -g @opengsd/gsd-core@canary

# Pin to an exact canary version
npm install -g @opengsd/gsd-core@1.50.0-canary.1

The CC installer's defensive purge rewrites stale config blocks left by older GSD versions, so reinstalling on top of an existing project is safe.

When to install canary

✅ Do install canary when you want to:

Exercise in-flight planning/execution/verification features early and report findings
Validate a fix you've contributed to dev is reachable end-to-end
Help shake out canary-bake items (rough edges that won't ship to next until resolved)

❌ Do NOT install canary on:

Production projects you depend on for delivery
A machine where rolling back means recreating GSD state (use a profile or a workspace instead)
A demo or onboarding setup — pin to @latest so audiences see the stable surface

Rolling back from canary

# Back to the current stable
npm install -g @opengsd/gsd-core@latest

# Or to the next/RC train
npm install -g @opengsd/gsd-core@next

If you have a local project that interacted with canary-only features (for instance, an MVP-mode phase planned by 1.50.0-canary), the planner artifacts in .planning/ remain valid — older GSD versions will just ignore the **Mode:** mvp field on phases.

Reporting issues against canary

File against the issue tracker with the bug template. Include the exact canary version (gsd-core --version reports it) so triage can route the report back into the dev stream rather than the stable stream.

Where to look next

Active canary release notes: docs/RELEASE-v1.50.0-canary.1.md
Stable release notes: CHANGELOG.md
Stream architecture rationale: discussed across #2727, #2773 (codex schema-break and the resulting promotion bottleneck that motivated explicit stream isolation)

3.3 KiB Raw Blame History