docs: fix stale route-sharing → social-federation dependency
The roadmap claimed social-federation depends on route-sharing for public routes, but that prerequisite shipped independently via public-content-visibility (2026-04-24) and social-feed (2026-04-25): visibility columns, public profiles, and IRI-keyed follows are all in place. Reorder Phase 1 to reflect that federation can start now. Also flag route-sharing's proposal as needing re-scoping: tasks 1.1-1.3 and 3.1 duplicate already-shipped visibility work, and the proposed enum contradicts the shipped text-column design. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
f7002be0bd
commit
81ba2d5de3
2 changed files with 18 additions and 5 deletions
|
|
@ -1,3 +1,12 @@
|
|||
> **⚠️ Needs re-scoping before implementation (noted 2026-06-06):** This
|
||||
> proposal predates `public-content-visibility` (archived 2026-04-24), which
|
||||
> already shipped route/activity visibility as a plain-text column with three
|
||||
> values (`private | unlisted | public`), public detail pages, public profiles,
|
||||
> and an owner-facing visibility selector. Tasks 1.1–1.3 and 3.1 are obsolete
|
||||
> (and 1.1's enum approach contradicts the shipped text-column design — see
|
||||
> `packages/db/src/schema/journal.ts`). The remaining scope — per-user sharing
|
||||
> (view/edit), forking, contributor tracking — is still valid and unshipped.
|
||||
|
||||
## Why
|
||||
|
||||
Routes in the Journal are currently invisible to everyone except the owner. There
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue