flyemoji
096d59716e
Retroactively author 15 grouped detail docs covering the backend functional (feat/fix) commits made before the change ledger was established (fad48ff), closing the ledger's detail-doc axis for the pre-convention history. Each doc groups a feature's constituent commits, lists their SHAs with subjects, and carries a backfill note stating it was reconstructed from git history on 2026-07-07 and not independently re-verified (current tree green at9911b8c). Add a Detail docs section to INDEX.md linking every detail doc (the 6 existing + 15 backfill) to the commit(s) it covers, so a doc is findable from the index without a column on the auto-generated ledger table. Catch the table up with the missing9911b8crow. Scope: backend (Go/Java/K8s) only, per the ledger's stated convention that frontend/panel commits are the collaborator's UI work; non-functional commits (docs/style/chore/refactor) keep their table row without a dedicated detail doc.
1.8 KiB
Modpack submission lane: build/approval pipeline + storage backends (ledger backfill)
- Type: feature — retroactive ledger entry
- Date: 2026-06-26 – 2026-07-02
- Area:
internal/submit(build/approval pipeline, storage backends),internal/api(submission endpoints) - Commits:
d39605efeat(submit): user modpack build + approval pipeline — an uploaded modpack stayspending_reviewand is never built until an admin approves; approval is a single-winner compare-and-swap handing off to the image-build Job, keeping the mandatory vulnerability scan in front of any push598f3d3feat(submit): local + S3 backends for modpack upload contexts, installer-selectable
- Tasks: #24 (§8 user-submitted modpack approval lane)
What it did
Built the user-directed extension over the image-build subsystem: a player uploads a
modpack context, it sits in pending_review, and an admin's approval is the single-winner
gate that hands off to the build Job — with the vulnerability scan always ahead of any
registry push. 598f3d3 makes the upload-context store pluggable (local filesystem or S3),
selectable at install time.
Why
Untrusted user content must never build or push unreviewed, and the compare-and-swap approval guarantees exactly one build per submission even under a double-click or retry. The storage-backend choice lets a single-node demo use local disk while a real deployment uses S3, without a code change.
Backfill note. Reconstructed 2026-07-07 from the commit history. The approval compare-and-swap and endpoints were unit-tested at their commits; the S3 path is integration-configurable. The panel-side submission/approval UI is the collaborator's frontend work and is tracked only by its INDEX rows. Not independently re-verified for this doc; current tree green at
9911b8c.