0019 — Product roadmap: feature triage, UX direction & the hosted play¶

Status: DRAFT Owner: Matt Cockayne Last updated: 2026-07-10

What this is. 0016 (future features), 0017 (UX improvements) and 0018 (UI mockups) are raw brainstorm — a wide net cast during a quota-constrained week. This spec curates that net: it scores every idea against krites' identity, keeps the winners, reframes the near-misses, cuts the scope-creep, fills the gaps the brainstorm missed, and threads the survivors into a roadmap that can carry krites from "bespoke tool for Hailey" to "marketable product," including a hosted, multi-tenant subscription track.

It does not supersede 0001 — the master design still governs. Where a kept feature bends a 0001 non-goal (multi-tenant, delivery, DAM, manual develop), that tension is called out explicitly, because those non-goals were deliberate and moving them is a product decision, not a drive-by.

1. The lens: what makes a krites feature "strong"¶

Every idea below is scored against five questions. A strong feature answers yes to the first three; the last two decide when.

1. Does it deepen the moat, or scatter it? krites' defensible core is the cull — judging 4,000 frames fast, explainably, and to your taste. Features that make the cull faster/smarter/more-trusted compound. Features that bolt on a loosely-related capability (video, album layout, DAM) dilute focus and invite a war krites can't win against incumbents (Pixieset, Pic-Time, Premiere).
2. Does it respect the identity? Local-first, non-destructive, Lightroom-bridging, not a raster editor, not a catalogue, not a delivery platform (0001 §2).
3. Is it feasible without betraying the architecture? Pure-Go/WASM-safe engine, models behind provider seams, single binary + ORT dylib. Generative reliability and Adobe-format reverse-engineering are the two recurring feasibility traps.
4. Effort vs. differentiation. Cheap + differentiated = do it now. Expensive + me-too = don't.
5. Does it help sell to photographers who aren't Hailey? The bespoke tool and the marketable product are the same engine; the difference is trust, onboarding, coverage guarantees, and platform reach.

2. Triage of 0016 (the 33 proposed features)¶

Tiers: ADOPT-near (on-strategy, feasible, high ROI — schedule within Phases 1–3), ADOPT-later (strong but gated by a heavy dep or a later phase), REFRAME (good kernel, wrong framing/mechanism — keep the intent, change the shape), RESEARCH (compelling north-star, unproven feasibility/ethics — spike before committing), CUT (off-strategy or scope-creep).

Reading the table: the ADOPT column clusters into a small number of capabilities (faces, deterministic diagnostics, coverage, portable taste, generative retouch), not 33 disconnected features. §5 develops the survivors as those capabilities. The CUTs share a theme — they push krites past "judge the shoot" into "produce the deliverable," which is precisely the delivery/layout/video territory 0001 deliberately cedes to Pixieset/Pic-Time/Premiere.

3. Triage of 0017 (the 10 UX improvements)¶

The UX ideas are mostly strong and cheap — they're client-side Svelte on the 0014 refactor, they lean into the "feels native, keyboard-first, pro" identity, and they cost little. Two carry non-obvious traps.

Cross-cutting UX gaps the list missed: (a) a progress/throughput HUD during cull ("2,300 / 4,000 · ~7 min left · 1,850 keep") — the number that sells the tool; (b) bulk operations on a grid selection (reject-all-in-cluster, star-range); © an onboarding/first-run flow (see §4). These matter more to marketability than several of the polish items.

4. UI mockups (0018) — inspiration only¶

The 0018 images are low-fidelity mood-boards, provided purely for inspiration — not designs to be read literally or built to. The real artifact is a future high-fidelity wireframe that maps the true features and functionality (this spec's §5 tracks, the 0003 studio contract, the 0014 component structure); that wireframe pass is its own piece of work, drafted when the studio UI work is scheduled. So the notes here are about what signal to carry forward from the inspiration, not a critique of pixels that were never meant to be exact.

Carry forward:

• The visual identity. Aubergine / Gold / Cream, per-frame AI score badges, a clean side inspector, the filmstrip, Lightroom-muscle-memory tools — this is a marketable look and a good starting palette for the real wireframe.
• One system with modes, not five UIs. The five concepts are really modes of one app: "Pro Dark" grid + loupe as primary; Immersive Survey is the Survey Mode UX (§3 #7); Editorial Light is just the light theme; Floating Inspector / iPad is the Wails/tablet future (aligns with the existing LAN-bridge-to-tablet studio runs). Design the real wireframe as one component system with skins/modes.

Watch-fors when the high-fidelity wireframe is drafted (so the real screens stay on the right side of 0001's non-goals — the inspiration images drift across a couple):

• Keep develop look-based, not a slider stack. krites' develop is proposal- and look-based (0006), not a manual Exposure/Contrast/Highlights editor — that's the "curves panel" 0001 §2 rules out. Any WB/exposure control in the real UI should be a thin nudge on top of a look, not a Lightroom-lite develop module.
• Keep the library scoped to shoots, not a catalogue. A shoot library (list of shoots) is in scope; cross-library "Smart Collections / Best Of" is DAM framing (0001 §2: not a catalogue) and Lightroom's job.
• Show only real scores. Sub-scores like "Emotion / Composition / Lighting" imply the aesthetic model that 0007-DEC-1 ships inert until Phase 4. The real MVP UI shows the honest deterministic scores (focus/exposure/eyes/dedup) and greys the rest until the model lands — a fabricated "Emotion 92%" would be a trust own-goal.

5. The strong features, developed (grouped by capability)¶

The ADOPT survivors resolve into seven capability tracks. Each notes the provider seam it uses, the phase it fits, and what to build now to unblock it later.

5.A Explainable, faster cull — the near-term UX moat¶

(0016 #19; 0017 #3, #5, #7 — plus the throughput HUD)

This is where krites out-reviews Aftershoot and Narrative Select, and it's mostly cheap client work on the 0014-refactored, virtualised grid.

• Face zoom panels (#19): from the FaceAnalyzer bounding boxes, render a sidebar grid of 100%-crops of every face in the frame — instant per-face focus/eye verification without pan-and-zoom. This is Narrative Select's signature feature and our bounding boxes already exist; it's the highest-ROI single item in the whole brainstorm.
• Reasons heatmap (#5): hover a text reason → glow the exact region that caused it (the closed eye, the soft plane). Load-bearing prerequisite: the analysis record must persist per-issue coordinates (0004/0005 scope) — bake this into the analysis schema now, or the feature is a painful retrofit later.
• Focus peaking (#3): reuse the sharpness edge-energy map as a loupe overlay.
• Survey mode (#7): the burst-winner elimination game; the Immersive Survey mockup is its UI.
• Throughput HUD (gap): live "N/total · est. time · keep count." The headline marketing metric ("cull a full wedding in ~20 min") is generated here.

Do-now enabler: extend the analysis record to carry issue coordinates + per-face crops-by-reference. Everything else in this track is Svelte on top.

5.B People subsystem — face identity¶

(0016 #10 VIP/hero, #16 guest matrix, #9 vibe)

One capability — face embeddings + clustering behind the FaceAnalyzer seam — lights up three features:

• VIP/hero tracking (#10): match against a reference of the couple → bump keep score. Aftershoot ships this ("star by faces"); it's a direct cull reweight.
• Guest coverage matrix (#16): cluster all faces across the shoot → "every unique guest, and how well covered." Answers "did I miss anyone?"
• Vibe filter (#9): an expression-signal facet ("high energy / intimate"), a filter, not its own engine.

Privacy note: face recognition/identity is more sensitive than face detection. Keep embeddings local, per-shoot, never uploaded, and disclosed — this is a marketing strength (privacy-keeping) if handled openly, and a liability if not. Consent framing matters if this ever touches the hosted product.

5.C Deterministic diagnostics — engine-fit quick wins¶

(0016 #29 sensor dust, #12 mixed lighting, #5 gear analytics)

The most on-identity cluster: pure-Go, deterministic, WASM-safe, cheap, differentiated, low-risk. Each is a badge/dashboard, not a model.

• Sensor-dust flagging (#29): detect a persistent dark spot at identical coordinates across many frames (esp. narrow apertures). Deterministic; genuinely differentiated; nobody expects a culler to catch it.
• Mixed-lighting warning (#12): flag extreme colour-temperature conflict pre-edit.
• Gear analytics (#5): cross EXIF × quality scores → "your 35mm f/1.4 motion-blurs 3× more at receptions." Near-free from data we already have; strong engagement hook.

These are ideal early, visible, low-risk wins that also reinforce the WASM-safe engine discipline (0001 §12.1).

5.D Coverage & completeness — the B2B lever¶

(0016 #30 CRM shot-list + #25 album-gap, merged)

One coverage checklist: a built-in wedding-beats template (rings, dress, first kiss, cake, family groups) and an importable CRM/HoneyBook shot list. The studio requires the photographer to tag a keeper to each item; export warns on gaps. This is the feature that sells to studios (contracts, must-haves, associate shooters), not just solo Hailey — a real marketability multiplier.

5.E Multi-source ingest — second-shooter sync¶

(0016 #7)

Two cameras with drifted clocks is a universal two-shooter headache. Detect visual overlaps (flash bursts, shared scenes) → compute the ms offset → align a single virtual timeline. An ingest capability (multi-source import + time normalisation), deterministic-ish, and a credible "krites gets your whole day, not one card" story.

5.F Portable taste + the marketplace seed¶

(0016 #14, split)

• Now (trivial): .krites-look / .krites-profile export/import — a look/ profile is already config (0001 §6); serialising it is near-free and immediately useful (back up, move machines, share with a second shooter).
• Later (SaaS pillar): the hosted marketplace to discover/buy/sell profiles & looks — see §6. The portable file format is the substrate; the marketplace is the business.

5.G Export reach¶

(0016 #13 sneak peek, #11 9:16 crop, #31 vendor routing)

Bounded extensions of export, not a delivery platform:

• Sneak-peek (#13): auto-select 10–15 diverse top keepers → a standalone folder. ADOPT-near (quick win).
• 9:16 social crops (#11): saliency-driven vertical crops; reuses develop's crop engine. A marketable export option.
• Vendor routing (#31): scene/object detection → per-vendor export folders (florals, cake, venue). Gated on scene detection; a studio-workflow multiplier.

Guardrail: these produce files on disk, not client galleries. The moment "export" grows accounts, links, and downloads, it's competing with Pixieset — cede that (except the collaborative proofing seam, which is the hosted product, §6).

5.H Generative retouch — later, gated, reliability-first¶

(0016 #1 group composite, #21 specific models, #20 dodge/burn; RESEARCH: #2, #23)

All behind the Inpainter/segmentation seams, Phase 3+, sequenced individually, each shipped only when it's reliable enough to trust on a paying client's wedding. Non-negotiable framing (§8-3): every generative op produces an edited copy — the original is never touched — and for paying customers the amount of generative processing is a per-subscriber config option, not a fixed ceiling. So the list below is an engine-capability ambition, gated per-user by comfort, not a promise applied to everyone:

• Perfect-group eye-swap (#1): the headline — patch open eyes from adjacent burst frames into the best base. High value, high alignment/blend risk. Flagship Phase-3+ candidate.
• Specific retouch models (#21): stray hair, glasses glare, wrinkle-smoothing — the Evoto moat, each its own ONNX model under bounded retouch.
• Adaptive dodge/burn (#20): segmentation-driven subject/background relighting at export.
• Shared enabler: #20, #31, and the Lightroom-mask idea (#2) all want a segmentation provider — add it once, behind a seam, and three features unlock.
• RESEARCH before promising: #2 (Lightroom AI masks → XMP) is strategically the best of these (it deepens the 90% Lightroom bridge and offloads Lightroom's slow masking) but hinges on Adobe's undocumented mask XMP format — spike feasibility first. #23 (per-shoot LoRA) is a north-star with an ethics gate (fabricating a real person's face/expression); research and consent framing, not a schedule slot.

5.I The learning loop — Phase 4, restated¶

(0016 #33, #26)

Already the master roadmap's headline (0001 §11 Phase 4). #33 (personal aesthetic classifier) is the model; #26 (second-guess/fatigue fighter) is a lovely UX surface for it — "you usually love shots like this; tired, or reconsider?" The substrate is being built now (0005 decision capture, 0009 review). Nothing new to schedule; note #26 as the Phase-4 studio deliverable.

6. The hosted, multi-tenant subscription product¶

This deliberately elevates 0001 §12 ("could it be a product?") from a guarded possible future into a planned track, and softens the "not a delivery / not multi-tenant" non-goals on purpose. That is a genuine product decision — flagged here, not smuggled — and it's gated so it never distorts the single-user engine's design (the §7 sequencing keeps it last).

6.1 The unlock: privacy-preserving SaaS via client-side inference¶

The naïve hosted culler uploads a wedding to a GPU farm — expensive per tenant, and it detonates krites' one true differentiator (privacy). The architecture already resolves this (0001 §12.1): the deterministic engine is Go→WASM-compilable, and the same ONNX models run in-browser via ONNX Runtime Web + WebGPU. So the hosted product can run the heavy compute in each user's own browser (or their own local krites agent) while the server holds only a thin control plane.

Consequence — the pitch writes itself: "Cloud convenience, local privacy — your photos never leave your machine, even in the hosted app." That is a genuine moat against Aftershoot/cloud cullers, and it caps our COGS (no per-tenant GPU bill).

6.2 Architecture — thin control plane, heavy edge¶

• Server holds (small, cheap, multi-tenant): accounts/auth/billing; shoot metadata and verdict/edit records (YAML/JSON — kilobytes, never the RAWs); profile/look sync; the marketplace; collaboration/proofing state; licence checks.
• Client holds (heavy, private, zero server COGS): decode, analysis, inference, render — via WASM + ORT-Web/WebGPU in the browser, or a local krites binary acting as the tenant's compute agent ("bring your own compute"), with the studio as a thin web client to it.
• Optional paid cloud compute: for users who want best-in-class cloud models and knowingly opt in (the existing per-capability cloud provider seam + disclosure contract, 0001 §5 / R-PRIV-*) — sold as metered credits, never the default.

This is purely additive to the provider architecture: hosted = a new auth/sync/ billing shell + the ORT-Web adapter, not a re-architecture. The single-user engine is unchanged.

6.3 Tiers & monetisation (illustrative)¶

Monetisation pillars: (1) Pro subscription — the backbone; (2) Studio seats — the expansion; (3) marketplace take — the network; (4) optional cloud credits — usage upside. Ordered by build priority: 1 → 3/portable-files → 2/proofing → 4.

6.4 Collaborative cull proofing — the SaaS on-ramp (reframed #4)¶

0016 #4 (WASM client proofing) is the seed, reframed to stay on-strategy. Not a Pixieset-style delivery gallery (that remains a non-goal). Instead, a cull collaboration surface — the photographer shares a lightweight, WASM-powered proof of the maybe/keep set; the couple or a second shooter marks selections in-browser; choices flow back as verdict records. It extends the cull moat (getting the decision right, together) rather than competing on delivery. It is the natural first hosted feature: minimal server (share links + selection state), maximal reuse of the WASM engine, and it dogfoods §6.1.

6.5 The tension to own¶

The hosted track knowingly relaxes two 0001 §2 non-goals: "not multi-tenant" and "not a delivery/proofing platform." Kept honest by three rules: (a) it's last in the sequence (§7) so it never bends the single-user engine's design; (b) proofing is cull collaboration, not gallery delivery — the delivery-platform non-goal still mostly holds; © privacy is preserved by architecture (§6.1), so the pivot to SaaS doesn't cost krites the thing that makes it krites.

7. Gaps the brainstorm missed (and that "marketable" demands)¶

The brainstorm optimised for more features; a marketable product needs these foundational items more than most of §5:

• Platform reach (resolved, §8-1). krites is Mac/arm64-first (0001 §13-Q6). The posture is now settled: the web/hosted route makes platform moot (browser = the platform); the local route ships Linux + macOS first, a Windows "lite" variant deferred, full Windows a long-tail. The pure-Go engine is already portable; the only Mac-bound piece is the CoreML ORT execution provider, swappable behind the seam (CPU/DirectML/CUDA EPs). So this is packaging/build work, sequenced after Hailey is live — not a fork that reshapes the engine.
• First-run taste calibration / onboarding. The "learns your taste" promise (Phase 4) has a cold-start problem. A "rate these 50 frames to teach krites" wizard gives day-one personalisation and a killer demo. Currently unspecified.
• Trust & accuracy reporting. Aftershoot markets on trust: "krites agreed with you 94% of the time," confidence surfacing, an easy override→learn loop. This is a retention/marketing gap, and it's cheap given 0005 already captures the data.
• Throughput as the headline metric (also §5.A). The "cull 4,000 in ~20 min" number needs to be measured, shown, and marketed.
• Licensing & activation mechanics. The actual business plumbing — licence keys, activation, entitlement per tier — is unspecified. 0010 (packaging/update) is the natural home to extend.
• Incremental / resumable ingest. Re-ingesting a card, adding a second card mid- shoot, resuming an interrupted import — robustness the brainstorm skipped.
• Bulk operations & selection ergonomics (also §3) — reject-whole-cluster, star-a-range; table-stakes for 4,000-frame throughput.

8. Decisions (RESOLVED 2026-07-10)¶

1. Market posture — two paths, no premature commitment.
2. Web / hosted route: cross-platform is moot — the frontend only has to run in the user's browser, so the browser is the platform. No native Windows work is implied by the SaaS direction.
3. Local route: market for Linux + macOS first, then a deferred Windows "lite" variant, with a full Windows variant as a long-tail future. (Engine note: the deterministic pkg/ engine already builds on Linux; the Mac-only piece is the CoreML ONNX execution provider — a Linux/Windows local build points ORT at a CPU/other EP behind the same seam, so this is a build/packaging matter, not a re-architecture.)
4. SaaS timing — long-term goal, not a near-term driver. The hosted track (§6) stays a long-term goal. The short-term priority is a working, single-user, local krites ready for Hailey to use. SaaS must not distort near-term sequencing — so portable profiles/looks, the WASM-safe engine discipline, etc. are built for Hailey's own value (backup, moving machines, instant re-resolve), and happen to be SaaS on-ramps later — they are not scheduled as SaaS scaffolding.
5. Generative & the sacrosanct original. Originals are never touched — full stop (reaffirms the non-destructive guarantee, 0001 §3/§4.6). krites only ever produces edited copies. Generative features therefore have no fixed ambition ceiling at the engine level; instead, once there are paying customers, the generative comfort level becomes a per-subscriber configuration option giving the subscriber full control over how much generative processing they permit. The trust boundary is a config surface owned by the user, not a hardcoded roadmap limit.

9. Consolidated roadmap¶

Threading the survivors into the existing phase structure (0001 §11) and queued specs (0008/0009/0010/0011/0014). New work from this spec in bold.

North star (§8-2): a working, single-user, local krites in Hailey's hands. Phases 1–4 below serve that first; the platform and hosted tracks are explicitly downstream of it and must not pull focus forward.

9.1 Near-term execution order — studio (this session)¶

Priority set 2026-07-10: UX fixes first, then the interface redesign. CI/CD and packaging (0010, and the 0011 re-platform foundation it needs) are being handled in a parallel krites session on the MacBook — off this session's critical path. The list below is the immediate drilldown; the phase view above is the strategic frame.

• Stage 0 — foundation (0014, and it is the first UX fix). The biggest live UX defect is that the grid isn't virtualised (janky/heavy at 4,000 frames) on a 1,400-line Review.svelte monolith. So UX work starts with the 0014 refactor: TanStack-Virtual grid + componentisation (Grid / Loupe / InpaintMask / CompareBurst) + Vitest/Playwright, under the 0015 skill. Everything below sits on this.
• Stage 1 — design-independent UX features (behaviours that survive any reskin, so safe to build on the current UI): directory-picker fix (server-side native dialog, §3 #1); focus peaking (§3 #3); reasons heatmap (§3 #5 — backend dep: land the analysis record persisting per-issue coordinates first); survey mode (§3 #7); lights-out (#9); before/after wiper (#8); exported-files toggle (#2); plus the gaps — throughput HUD and bulk-selection ops.
• Stage 2 — interface redesign. The high-fidelity wireframe (the 0018 successor — one design system with modes, guardrails per §4) → restyle/rebuild the now-componentised UI onto it (cheap because of Stage 0). Fold the layout/skin-level UX items (grid pinch-reflow #6, shortcut HUD #10, native gestures #4) into the redesign rather than building them twice.

Anti-rework rule (agreed 2026-07-10): in Stage 1 build only the behavioural UX (it carries over untouched); let the redesign absorb anything layout/skin-level. Polishing screens the redesign will replace is the one waste to avoid.

DECISION — default grid layout (2026-07-12). The 0014 engine ships uniform / justified / masonry; the studio's shipped default is justified rows, with a Rows / Grid toggle to uniform (persisted in localStorage). Rationale: for a wedding cull the core task is fast sequential triage of near-duplicate bursts, so shot order must be preserved (masonry scrambles vertical sequence — disqualified as a default) and frames should show uncropped to judge framing/expression (uniform crops to fill). Justified keeps strict reading order at a consistent scan height and is the Lightroom idiom Hailey knows. Masonry stays in the engine but is not user-surfaced. This is a behavioural choice that carries into the redesign; the redesign still owns pinch-reflow (#6) and the final skin. Implemented in Toolbar/Review/cullSession behind the existing e2e net.

Stage-1 progress (2026-07-12). Landing on feat/studio-ux (MR !46), all behavioural so they survive the redesign: lights-out (#9), bulk star-rating + select-burst and the throughput HUD, survey mode (#7), and the before/after wiper (#8, needed a new ?develop=original preview variant server-side). Still open in Stage 1: focus peaking (#3) and the reasons heatmap (#5) — folded into the explainable-cull track (next), which is spec-gated because it changes the analysis record. Directory-picker fix (#1) and exported-files toggle (#2) remain unstarted.

Gate CLEARED — reassessment done (2026-07-10). The MacBook session landed and cut release v0.4.4 (signed/notarized .dmg). Re-reading the true lie of the land on main (ad79497):

• 0011 re-platform — IMPLEMENTED. GTB now at v0.29.0 (past the v0.27.2 target); the studio runs on controls-managed http + cookie/bearer auth. The Stage 0 blocker is gone.
• 0010 packaging — IMPLEMENTED. Signed/notarized macOS .dmg ships from CI (v0.4.4).
• Also landed while we were scoping: 0012 (config lifecycle, first-run krites init, global settings panel + global→shoot config cascade — IMPLEMENTED) and 0013 (ONNX Runtime auto-provisioning — IN PROGRESS, slice 2 the one loose end). These are infra under the studio; they don't alter the UX→redesign plan but are now part of the landscape.
• Frontend unchanged for our purposes: Review.svelte is still a 1,498-line monolith (components: App / Library / Review / Settings / GlobalSettings). The MacBook work was packaging + config, not the UI refactor — so Stage 0 (0014) stands as the correct next move, now on the solid v0.29.0 foundation.

This session is UN-PAUSED. Stage 0 may begin. Watch-outs surfaced by the reassessment: the new global-settings panel (0012) and any 0011 auth/route changes are the current API/component surface Stage 0 must refactor against — read them before slicing 0014.

• Phase 1 — cull MVP (in flight): ingest → quality/eye/dedup → studio review → export + XMP. Fold in the §5.A explainable-cull track (face zoom panels, reasons heatmap, focus peaking, survey mode, throughput HUD) as it rides the 0014 grid refactor — this is the near-term differentiation. Add the §5.C deterministic diagnostics (sensor dust, mixed-lighting, gear analytics) as low-risk visible wins. Ship portable profile/look export/import (§5.F). Fix the directory-picker mechanism (§3 #1). Add first-run taste calibration + throughput metric (§7).
• Phase 2 — develop (implemented; retouch pending): add the §5.B people subsystem (VIP/hero, guest matrix — face embeddings), coverage checklist (§5.D), second-shooter sync (§5.E), sneak-peek + 9:16 export (§5.G). Begin bounded specific-retouch models (#21) and the segmentation provider enabler.
• Phase 3 — object removal (in flight, 0008): generative retouch track (§5.H) — perfect-group eye-swap (#1), adaptive dodge/burn (#20), vendor routing (#31). Spike Lightroom-mask/XMP feasibility (#2). Reliability-gated.
• Phase 4 — learns your taste: personal aesthetic classifier (#33) + second-guess fatigue-fighter UX (#26) + trust/accuracy reporting (§7).
• Platform track (after Hailey is live, §8-1): Linux + macOS first, then a Windows "lite" variant, full Windows long-tail; Wails native app (already Wails-ready per 0001 §10) — home for native gestures (§3 #4) and the Floating-Inspector/iPad mockup. Packaging work, not an engine change.
• Hosted track (long-term, §6 / §8-2): deliberately last, and it does not drive near-term sequencing. When it comes: portable formats (already shipped in P1 for Hailey's own value) → collaborative cull proofing (§6.4, the WASM on-ramp) → accounts/billing/sync + Studio tier → marketplace (#14) → opt-in cloud-compute credits.
• Researched, unscheduled: per-shoot LoRA (#23), generative focus-rescue (#27), voice culling (#3). Cut / possible sibling products: album/blog layout (#6/#18), video/slideshow (#15/#24), PJ metadata (#22).

10. Status of the source docs¶

• 0016, 0017, 0018 are retained as brainstorm input (superseded as a roadmap by this spec, not deleted). 0018's images are low-fidelity inspiration only — a proper high-fidelity studio wireframe (true features/functionality, on the 0003 contract + §5 tracks) is a separate future deliverable, drafted when the studio UI work is scheduled.
• This spec is DRAFT pending the §8 decisions. On sign-off, the ADOPT-near items fold into their phase specs (new R-* requirements), and the hosted track earns its own spec (à la 0003) when §8-Q2 says "now."