sksizer/sdlc is sdlc's product home and self-hosted marketplace

State: open/accepted

Summary

sksizer/sdlc — not sksizer/marketplace-sdlc — is where the sdlc product ships and lives going forward. It is the target of the v0.4.0 public release and every release after it, published as a self-hosted, single-plugin marketplace at its own repo root.
This reverses sksizer/sdlc’s archived status, set when development moved into this monorepo (see Why). The repo’s git history — the Python-era sdlc predecessor’s own commits — is kept, not rewritten; the new product tree lands on top of it as a normal commit. See Migration.
sksizer/marketplace-sdlc stays in service as a separate, unrelated catalog — a pre-existing multi-plugin marketplace this decision does not touch or retire. sdlc simply stops publishing there.
npm publish (T-7H3A) becomes more feasible once sdlc’s target is its own dedicated repo rather than a pack woven into somebody else’s marketplace: the buildable CLI source tree the npm artifact needs has an obvious, uncontested home to land in.
Later, not now: sdlc’s own TypeScript source and libraries move into sksizer/sdlc too, at which point sksizer/dev becomes a repo that consumes published sdlc packages rather than hosting sdlc’s source. See Migration and Consequences.

Context

sksizer/sdlc is the original home of sdlc — a Python-era tool whose last commit (e2d1b12f0) predates this monorepo, carries no tags and no LICENSE. Development moved into sksizer/dev (solutions/ontological, the bun/node rewrite tracked by RM-E2L0) some time ago, and sksizer/sdlc’s GitHub repo description was updated to reflect that: “SUPERSEDED by sksizer/dev (D-0015 Dark Factory target architecture) — archived.” That D-0015 (“Dark Factory target architecture”) is not a decision that exists as a file in this repo today — the supersession map executed in 434bd0529 deleted it and folded its content into D-VSLI-distributed-work-runner-architecture (see that file’s own supersession table). The repo-description text is the only surviving record of the original numbering.

Separately, T-2A6R built scripts/sdlc-mirror/assemble.ts to publish sdlc’s plugin into sksizer/marketplace-sdlc — a pre-existing, unaffiliated multi-plugin marketplace repo this monorepo does not own, requiring a surgical merge (mergeSdlcPackIntoTarget) so sdlc’s pack never clobbers that repo’s other plugins. T-ZZRC wired publish-libs.json’s sdlc entry at that mirror, and the release checklist for v0.4.0 (docs/planning/notes/N-EAYX-sdlc-0-4-0-release-checklist.md) was written against it. sksizer/marketplace-sdlc PR #25 — the first attempt at landing sdlc there — is closed as part of this decision.

Decision

sdlc’s public release target for v0.4.0, and every version after it, is sksizer/sdlc, not sksizer/marketplace-sdlc. sksizer/sdlc becomes a self-contained product repo: a --layout product mode in scripts/sdlc-mirror/assemble.ts replaces the entire target tree (the old Python-era content removed via ordinary tracked-file deletion, never a history rewrite) with the rendered plugin trees for all three harnesses (.claude-plugin/, .agents/, .cursor-plugin/, each self-hosting its own marketplace manifest naming the single sdlc plugin) plus a root README.md, LICENSE (MIT), .gitignore, and CHANGELOG.md carried from the product. sksizer/marketplace-sdlc keeps existing as the separate multi-plugin catalog it always was — sdlc’s roster entry in publish-libs.json simply points mirror at sksizer/sdlc instead.

The first push (v0.4.0) runs as a PR-based flow — branch, commit, push, gh pr create against sksizer/sdlc’s main — run by the user, never by an agent, given how much of the existing tree that first push removes. Ongoing releases keep using release-lib.ts/publish-lib.yml’s existing tag-triggered mechanics, unaffected by this change beyond the mirror field.

Why

Hosting sdlc’s public release inside sksizer/marketplace-sdlc was always a workaround: that repo is somebody else’s pre-existing multi-plugin catalog, not sdlc’s own home, and every assemble run has to merge around content sdlc doesn’t own (mergeSdlcPackIntoTarget’s whole reason to exist). sksizer/sdlc already carries sdlc’s name and its original project history — reclaiming it as the product’s home is more honest about what sdlc is (a distinct, complete product) than continuing to publish it as a guest pack in someone else’s marketplace. It also removes the surgical-merge complexity from the common case: a repo sdlc owns outright can be replaced wholesale on release, which is both simpler to implement and easier for a human to review.

Consequences

scripts/sdlc-mirror/assemble.ts carries two layouts now (--layout product, --layout marketplace) instead of one; the marketplace-shaped surgical merge stays available for any future target that genuinely needs it.
The v0.4.0 release checklist, PUBLISHING.md, the sdlc 0.8 plan’s Phase 14, and the sdlc 0.8 atlas’s Phase 14 note are updated to name sksizer/sdlc as the release target; docs describing sksizer/marketplace-sdlc’s own mechanics as a separate catalog are left as they are.
sksizer/sdlc’s protected-checkout guard (checkProtectedCheckout in assemble.ts) now refuses a real checkout of sksizer/sdlc the same way it already refused a real checkout of sksizer/marketplace-sdlc — --target-is-scratch is required for either.
T-7H3A (npm publish) is easier once there’s no question of where the buildable CLI source tree lands — sksizer/sdlc’s own root has no competing multi-plugin structure to reconcile with.

Migration

Not part of this decision’s immediate scope, but the natural next step: move sdlc’s own TypeScript source and its @sksizer/* library closet into sksizer/sdlc itself, so that repo hosts sdlc’s development as well as its release, and sksizer/dev becomes a repo that consumes published sdlc packages rather than hosting sdlc’s source (solutions/ontological). A backlog/future-milestone task tracks this follow-up; see the roadmap link below. Until that lands, the vendored- tarball closure assemble.ts already computes and packs stays exactly as it is — v0.4.0 changes WHERE the assembled product lands, not HOW its dependency closure is built.

Open questions

Whether sksizer/sdlc’s own .github/workflows/ gets a CI setup as part of this migration, or waits until the TS-libraries move lands — out of scope for v0.4.0’s assembler work either way.
Exactly when the TS-libraries move (see Migration) gets scheduled relative to the rest of the RM-E2L0 roadmap.

Notes

sksizer/sdlc’s GitHub repo description (“SUPERSEDED by sksizer/dev… archived”) is a GitHub-level administrative fact, not an entity in this corpus — updating it is on the user, not part of this decision’s own mechanics.

← Back to Decisions