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.
31 lines
1.8 KiB
Markdown
31 lines
1.8 KiB
Markdown
# 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:**
|
||
- `d39605e` feat(submit): user modpack build + approval pipeline — an uploaded modpack stays `pending_review` and 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 push
|
||
- `598f3d3` feat(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`.
|