Correct §22 three-tier spec: two-tier model already shipped (v0.39.0)
Re-checked code vs the stale memory: migration 028 (slug PK -> (project_id, slug)), v0.35.0 /p/<project>/ routing, and v0.37/0.38 per-project read+propose are all shipped to main. The 'fold into not-yet-shipped Plan B + M3-frontend' premise is false. Neutralize the wrong claims in §0/§A.3 and flag Part E's sequencing as pending re-decision; structural model (Parts A-D) unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ben Stull
@@ -10,8 +10,18 @@
|
||||
> semantics, the `type`/`initial_state`/`unreviewed` machinery) carry over
|
||||
> unchanged, re-homed onto the collection. Rationale and the decisions behind
|
||||
> this live in [`multi-project.md`](./multi-project.md) and session 0072.
|
||||
> Target release: folded into the not-yet-shipped §22 work (Plan B + M3-frontend),
|
||||
> a pre-1.0 minor carrying breaking changes with upgrade steps (§20.2).
|
||||
>
|
||||
> ⚠️ **CORRECTION (session 0072, after code re-check).** Parts of §0/§A.3/§E
|
||||
> were drafted on a stale-memory premise that "Plan B (migration 028) and
|
||||
> M3-frontend have not shipped." **That is false.** As of v0.39.0 the entire
|
||||
> **two-tier** model is shipped to `main`: migration 028 already rebuilt the
|
||||
> slug PK to `(project_id, slug)`; v0.35.0 shipped `/p/<project>/` routing and
|
||||
> the live `/p/<project>/e/<slug>` URLs; v0.37.0/0.38.0 shipped per-project
|
||||
> read + propose. Inserting the third tier is therefore an **evolution of a
|
||||
> shipped system**, not a revision of unshipped designs. The migration strategy
|
||||
> (Part E) is **pending re-decision** with correct facts; the structural model
|
||||
> (Parts A–D) is unaffected. Target release: a further pre-1.0 minor with
|
||||
> breaking changes + upgrade steps (§20.2).
|
||||
|
||||
---
|
||||
|
||||
@@ -29,9 +39,11 @@ the original §22 said about a corpus (type, slug namespace, catalog, philosophy
|
||||
landing state, review flag, membership) moves down one level to the collection;
|
||||
the deployment level is unchanged.
|
||||
|
||||
The timing is favorable: the breaking slug-PK rebuild (Plan B / migration 028)
|
||||
and the public `/p/<id>/` routing (M3-frontend) **have not shipped**, so this is
|
||||
a revision of in-flight *designs*, not a rework of shipped surfaces (§7).
|
||||
⚠️ The two-tier model is **already shipped** (v0.39.0): migration 028 rebuilt
|
||||
the slug PK to `(project_id, slug)`, and `/p/<project>/e/<slug>` URLs are live
|
||||
(v0.35.0). So inserting the third tier evolves a shipped system — see the
|
||||
corrected Part E for the real migration cost (a new migration 029 + a breaking
|
||||
URL change with 308s), pending re-decision.
|
||||
|
||||
---
|
||||
|
||||
@@ -166,10 +178,12 @@ collections** in that project the visitor can see. Conveniences:
|
||||
- `/` redirects to the sole visible project when there is exactly one (the N=1
|
||||
case, §A.6).
|
||||
|
||||
Backcompat is light: no `/p/<id>/` URL ever shipped (M3-frontend is unmerged).
|
||||
The only live legacy URLs are the pre-multi-project `/rfc/<slug>` /
|
||||
`/proposals/<n>`, which **308-redirect** to the migration's default project →
|
||||
default collection (§A.6).
|
||||
⚠️ **Backcompat is heavier than first drafted.** `/p/<project>/e/<slug>` URLs
|
||||
**are live** (v0.35.0), so adding the `/c/<collection>/` segment is a breaking
|
||||
URL change: the shipped `/p/<project>/e/<slug>` must **308-redirect** to
|
||||
`/p/<project>/c/<default-collection>/e/<slug>`, alongside the pre-multi-project
|
||||
`/rfc/<slug>` → `/p/<default-project>/c/<default-collection>/…` redirect. Both
|
||||
are handled in the migration (§A.6 / Part E).
|
||||
|
||||
---
|
||||
|
||||
@@ -465,11 +479,21 @@ Applied in place when §22 is rewritten; listed here as the change surface.
|
||||
|
||||
# Part E — Revised slicing plan (the roadmap re-slot)
|
||||
|
||||
Strategy (session 0072 decision): **fold the third tier into the not-yet-shipped
|
||||
work** rather than ship two-tier and migrate again. M1, M2, and M3-backend
|
||||
Plan A are additive and already merged (v0.39.0); they keep running. The tier
|
||||
goes in at the **first breaking migration (Plan B / 028)** and the **first
|
||||
public routing (M3-frontend)**, before either ships.
|
||||
> ⚠️ **PENDING RE-DECISION (session 0072).** The strategy below assumed Plan B
|
||||
> and M3-frontend were unshipped. They are shipped (v0.35.0–0.39.0). The "fold
|
||||
> into not-yet-shipped work" framing is void; the actual work is a **new
|
||||
> migration 029** that evolves the shipped two-tier schema to three tiers, plus
|
||||
> a **breaking `/p/<project>/e/<slug>` → `/p/<project>/c/<collection>/e/<slug>`
|
||||
> URL change with 308s**. The two live mapping options (relabel today's
|
||||
> project → collection + insert a group tier above, vs. add a collection
|
||||
> sub-grain beneath today's project) are being put back to the operator. The
|
||||
> text below is retained only as the structural target, not the sequencing.
|
||||
|
||||
Strategy (ORIGINAL, premise now false): fold the third tier into the
|
||||
not-yet-shipped work rather than ship two-tier and migrate again. M1, M2, and
|
||||
M3-backend Plan A are additive and already merged (v0.39.0); they keep running.
|
||||
The tier goes in at the **first breaking migration (Plan B / 028)** and the
|
||||
**first public routing (M3-frontend)**, before either ships.
|
||||
|
||||
- **Landed, unchanged (v0.39.0):** M1 (additive `project_id` spine, mig 026),
|
||||
M2 (authz resolver), M3-backend Plan A (registry mirror, APIs, propose /
|
||||
|
||||
Reference in New Issue
Block a user