79002a00cb
* 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>
67 lines
3.3 KiB
Markdown
67 lines
3.3 KiB
Markdown
# 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
|
|
|
|
```bash
|
|
# 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
|
|
|
|
```bash
|
|
# 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](https://github.com/open-gsd/gsd-core/issues) 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`](RELEASE-v1.50.0-canary.1.md)
|
|
- Stable release notes: [`CHANGELOG.md`](../CHANGELOG.md)
|
|
- Stream architecture rationale: discussed across [#2727](https://github.com/open-gsd/gsd-core/issues/2727), [#2773](https://github.com/open-gsd/gsd-core/issues/2773) (codex schema-break and the resulting promotion bottleneck that motivated explicit stream isolation)
|