@therocketcode/gsd-core 1.8.3 → 1.8.4
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/.claude-plugin/plugin.json +1 -1
- package/gemini-extension.json +1 -1
- package/gsd-core/references/cicd-strategy.md +11 -0
- package/gsd-core/references/infrastructure-strategy.md +4 -0
- package/gsd-core/workflows/cicd-strategy.md +2 -0
- package/gsd-core/workflows/infrastructure-strategy.md +2 -0
- package/package.json +1 -1
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "gsd-core",
|
|
3
3
|
"displayName": "GSD Core",
|
|
4
|
-
"version": "1.8.
|
|
4
|
+
"version": "1.8.4",
|
|
5
5
|
"description": "GSD Core is a meta-prompting, context engineering, and spec-driven development system for AI coding agents.",
|
|
6
6
|
"author": {
|
|
7
7
|
"name": "TheRocketCodeMX",
|
package/gemini-extension.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "gsd-core",
|
|
3
|
-
"version": "1.8.
|
|
3
|
+
"version": "1.8.4",
|
|
4
4
|
"description": "GSD Core — a meta-prompting, context engineering, and spec-driven development system for AI coding agents. Loads gsd's operating context into every Gemini CLI session.",
|
|
5
5
|
"contextFileName": "GEMINI.md"
|
|
6
6
|
}
|
|
@@ -77,6 +77,17 @@ The invariant at every rung (DORA + SRE Workbook + Charity Majors converge): **s
|
|
|
77
77
|
|
|
78
78
|
**Canary ANALYSIS prerequisites (SRE Workbook ch. 16 — all required):** ~**a dozen trustworthy, low-variance SLI-derived metrics**, real traffic volume that yields signal on a 1–5% slice, and deploy frequency exceeding human attention — on top of repeatable builds and automated deploys. Below that: rolling deploy + health checks + one-command rollback. Use "the simplest model that meets your technical and business objectives." Plain blue-green is a "before/after canary" — risky because time is the largest source of metric variance.
|
|
79
79
|
|
|
80
|
+
## Publishing packages — the deploy ladder for shipped software
|
|
81
|
+
|
|
82
|
+
When the product ships as packages/binaries (CLI, library, SDK), the "deployment ladder" IS the publishing pipeline:
|
|
83
|
+
|
|
84
|
+
- **Tag-driven releases**: version tag → one release workflow builds, tests, publishes everything (never publish from a laptop; never build different artifacts per registry from different commits).
|
|
85
|
+
- **PyPI: Trusted Publishing** (OIDC — the official PyPA standard): no long-lived API tokens; the workflow identity is the credential, with the repo/workflow pinned on the PyPI side (the publishing analog of the pinned `sub`).
|
|
86
|
+
- **npm: `npm publish --provenance`** on CI — provenance attestation links the package to its source commit and workflow.
|
|
87
|
+
- **crates.io: scoped tokens** (no OIDC support yet) — token scoped to the crate(s), stored in an **environment-protected secret** with required reviewers on the release environment; rotate on release-process changes.
|
|
88
|
+
- **Signed/attested artifacts**: GitHub artifact attestations (free) or cargo-dist/goreleaser-class tooling for binaries + checksums; full cosign ceremony stays deferred until artifacts cross trust boundaries.
|
|
89
|
+
- **Release environment protection + manual dispatch** for anything that spends money or publishes — doubles as the fork-PR secrets-safety rule (publish workflows never run on fork PRs).
|
|
90
|
+
|
|
80
91
|
## Supply-chain table stakes (small team — all free, each ≤ hours, each counters a real 2023–25 attack)
|
|
81
92
|
|
|
82
93
|
1. **SHA-pin all third-party actions + Dependabot updating the pins.** tj-actions/changed-files (Mar 2025, **CVE-2025-30066**): attacker retroactively moved version tags to a malicious secrets-dumping commit, 23,000+ repos hit — tag pinning gave zero protection. Dependabot updates SHA pins with version comments, so "pins go stale" is solved.
|
|
@@ -8,6 +8,10 @@ The empirically safe prior, not a bias: real Kubernetes clusters average **8–1
|
|
|
8
8
|
|
|
9
9
|
The three inputs every crossover keys off: **traffic shape** (idle %, burst ratio), **team size**, **monthly compute spend**. Get these before recommending anything.
|
|
10
10
|
|
|
11
|
+
## Shipped software, not a service (check this FIRST)
|
|
12
|
+
|
|
13
|
+
When the product is **user-operated** — a CLI, library, desktop app, self-hosted binary — the operated-infrastructure footprint may legitimately be ≈ zero, and walking the compute ladder for it is over-engineering by this reference's own rule. The decisions shift to: **CI compute** (often the only compute you pay for — API-bound workloads need spend guardrails, not bigger runners), **release & distribution channels** (registries, GitHub Releases, installers — see the publishing section of `cicd-strategy.md`), **docs/results hosting** (Pages-class static hosting), and **API-spend guardrails** (provider billing alerts + workload kill-switches). Record the operated-service ladder only as **promotion-trigger material** for a future hosted tier — triggered, never pre-provisioned.
|
|
14
|
+
|
|
11
15
|
## The compute decision ladder
|
|
12
16
|
|
|
13
17
|
| Rung | Wins when | Move up when |
|
|
@@ -80,6 +80,8 @@ Map the tiers from TEST-STRATEGY.md onto the three stages (this is Google's stat
|
|
|
80
80
|
|
|
81
81
|
## Step 6: Deployment ladder rung
|
|
82
82
|
|
|
83
|
+
**Shipped-software route:** if the product ships as packages/binaries rather than an operated service, the ladder rung IS the publishing pipeline — walk the reference's "Publishing packages" section instead (tag-driven releases, PyPI Trusted Publishing, npm provenance, crates.io scoped+environment-protected tokens, attestations, fork-PR exclusion). The service ladder applies only to any future hosted tier, as promotion-trigger material.
|
|
84
|
+
|
|
83
85
|
Pick the rung from **team size + blast radius** (from Step 2), using the reference's ladder. Build-once/promote-same-artifact and one-command rollback are invariants at every rung.
|
|
84
86
|
|
|
85
87
|
- **Solo/small, low blast radius:** trunk-based + one automated deploy path + free platform PR previews (+ Neon-style DB branch per preview if Postgres) + one-command rollback. **No staging environment.**
|
|
@@ -56,6 +56,8 @@ If constrained: take it — the ladder is cloud-portable; use the reference's eq
|
|
|
56
56
|
|
|
57
57
|
## Step 4: Compute rung (walk the ladder per component)
|
|
58
58
|
|
|
59
|
+
**Shipped-software check first:** if the product is user-operated (CLI/library/desktop/self-hosted binary), do NOT walk the ladder for the product itself — the reference's "Shipped software, not a service" section governs: CI compute + distribution + docs hosting + spend guardrails; the service ladder becomes promotion-trigger material only.
|
|
60
|
+
|
|
59
61
|
For each deployable component from the ADR topology, walk the reference's ladder. **Default = serverless containers** (Cloud Run / ECS+Fargate / Container Apps). Only place a component on another rung when a concrete trigger from the reference fires — and record the trigger next to the rung.
|
|
60
62
|
|
|
61
63
|
- **Rung-down check (static/FaaS):** pre-renderable frontends → static/edge hosting; pure event-glue (webhooks, queue consumers, cron) → FaaS is fine *until* the FaaS→containers triggers: >15-min runs, WebSockets/streaming, connection pools / in-memory caches, or ~>15M invocations/month sub-second.
|
package/package.json
CHANGED