Runtime Continuation Batch 1 Phase 12F handoff → 5 A-owned runtime scaffolds · contract-bound previews · no mutation paths

Planning · v1.0 · all scaffolds shipped together

Batch นี้รวมงาน runtime continuation 5 ชิ้นจาก session_a_handoff.json (Phase 12F) ลงเป็น discoverable scaffolds ใต้ /runtime/*. เป้าหมายของ batch: ให้ runtime หาเจอได้จริงจาก Index Portal · ให้ human เห็นได้ว่า A รับงานไหนต่อจาก B · ห้ามปลอม mutation path · ห้ามอ้างว่า live ถ้ายังเป็น preview.

Rationale ทำไมรวมเป็น batch เดียว

Handoff 12F มี 10 items · ในรอบนี้เลือกเฉพาะ runtime items (wizard · enterprise-upload · intake-workspace · generated-assets · daily-queue) — 5 ชิ้นที่มี contract พร้อม ingest ทันที
ทั้ง 5 scaffolds ใช้ pattern เดียวกัน (fetch contract · render preview · expose index entry) → เหมาะกับการทำรวบ
Discoverability กระจายตัว: index-catalog ไม่ควรมี orphan — ทำครั้งเดียว update ทีเดียว
Planning consolidation เพื่อไม่ให้ /planning/* บวมด้วยหน้าเล็ก 5 หน้าซ้ำกัน

Handoff → A runtime surface mapping

Handoff item

B contract (read-only)

A runtime surface

hand-wizard-runtime
Premium Wizard interactive runtime

docs/kb/data/premium_wizard.json

/runtime/wizard/ → open

hand-enterprise-upload-runtime
Enterprise Upload + Hybrid Intake

docs/kb/data/enterprise_intake.json
docs/kb/data/source_mapping_engine.json
docs/kb/data/multi_source_intake.json

/runtime/enterprise-upload/ → open

(covered by enterprise-upload handoff)
Hybrid Intake workspace surface

docs/kb/data/hybrid_intake_workspace.json

/runtime/intake-workspace/ → open

hand-generated-assets-runtime
Generated Assets Navigator (SUB-1)

docs/kb/data/generated_assets.json
docs/kb/data/generated_assets_checklist.json

/runtime/generated-assets/ → open

hand-daily-possible-case-queue-runtime
Daily 07:00 possible-case queue

docs/kb/data/case_portal.json
docs/kb/data/ai_issue_analytics.json
docs/kb/data/alerting_model.json

/runtime/daily-queue/ → open

A-owned vs B-owned boundary per `session_a_handoff.json`

A-owned (this batch adds)

docs/runtime/wizard/ · enterprise-upload/ · intake-workspace/ · generated-assets/ · daily-queue/
This planning page · index-catalog + appendix entries · SYNC / SESSION_STATUS updates
All render JS is A-owned — fetches B contracts read-only, never writes

B-owned (read-only for A)

docs/kb/data/*.json (all contracts consumed above)
docs/kb/*.html (B shells referenced as peer links only)
docs/kb/assets/kb.js · kb.css · scripts/validate.mjs
docs/document_index.json · docs/kb/README.md

Route rationale ทำไมอยู่ path เหล่านี้

/runtime/wizard/ — mirrors established /runtime/<name>/ convention (feature-flags / admin-control-plane / cross-runtime-integration). Human searching "wizard" finds it via Index Portal.
/runtime/enterprise-upload/ — kebab-case noun · matches handoff item naming · readable by non-technical operators.
/runtime/intake-workspace/ — kebab-case noun · paired with enterprise-upload via peer links (no artificial hierarchy).
/runtime/generated-assets/ — kebab-case noun · "Generated Assets Navigator" collapses to this for URL economy while labels keep the full name.
/runtime/daily-queue/ — shorter than "daily-possible-case-queue" but still finds 07:00 / case / queue search terms via index_keywords.
All under /runtime/ — not /kb/ (KB is B-owned · spec/contract surfaces) · not under main-console top-level button (no new console button added per IA discipline).

Discoverability impact

5 new entries in index-catalog.json · 1 planning entry · search keywords cover wizard runtime, enterprise upload runtime, intake workspace, generated assets runtime, daily 07:00 queue, runtime batch, session a handoff, customization runtime, hybrid intake
Peer links cross-connect wizard ↔ intake-workspace ↔ enterprise-upload (hybrid triangle) · daily-queue ↔ case-portal planning · generated-assets ↔ generate-runtime planning
Every surface has breadcrumb → Console → Operations → Batch-1 plan → surface · back links included

Honest scope / non-scope

In scope (Batch 1)

Contract-bound preview surfaces under /runtime/*
Index exposure so Index Portal finds them
Honest labels · breadcrumbs · back links
1 consolidated planning page

Out of scope (deferred)

Interactive form state / persistence / auth
File upload · OCR · PII scan · PDF parse
AI suggestion runtime (CLAUDE.md Layer F)
Real cron · source monitoring · alerting delivery
Reviewer assignment · sign-off capture · promotion API
Mutation paths to any B-owned file
DOC-017 / DOC-023..026 formal authoring
Cross-tenant marketplace payments (explicitly out per handoff)

Next batches (operator note)

Batch 2 — delivered · wizard step navigation + localStorage draft · generated-assets per-card local reviewer note + claim · daily-queue simulated live countdown · all client-only · no mutation path
Batch 3 — real auth on wizard · FF gate for premium-tier cohort · approval-queue binding for sensitive-surface
Batch 4 — deployable cron skeleton for daily 07:00 queue (local dev only first) · structured alerting payloads (no delivery yet)
Later — once 2b boundary + A-owned audit trail are in place, enable one promotion path (generated-assets · draft→review only) gated by approval_matrix

Batch 2 addendum client-only interactive state · no server · no B write-back

Surface

Added in Batch 2

Storage · honesty

/runtime/wizard/

Step-nav buttons · progress bar · Save/Reset draft · click step card to activate

localStorage["ptt_wizard_draft_v1"] · browser-local · never sent

/runtime/generated-assets/

Per-card "📝 Claim review (local)" toggle · textarea reviewer note · Save/Clear · metadata line

localStorage["ptt_gen_review_notes_v1"] · does NOT write to B registry

/runtime/daily-queue/

Simulated live countdown per cell · pause/resume · reset baseline · intake-elapsed label

In-memory only · no persistence · no real cases · no real cron

Batch 2 preserves the Batch 1 invariants: contract-bound · no mutation path · no B write-back. Intake-workspace + enterprise-upload scaffolds are unchanged in Batch 2 — both still render contract only. Surgical fix 423c0e4 (Ops Portal strip · append-only) is logged as the first corrective step in Batch 2's commit record.

Batch 3 addendum Admin 2b hardening · FF 2b+ hardening · tenant rollout · hint system · append-first

Batch 3 is a local-dev hardening batch. No public endpoint changes · no write-back to B · no new main-console buttons. Scope is explicit: deepen Admin 2b + FF 2b+ contract artefacts · stamp tenant rollout badge + contract-sourced hint panel on all 5 Batch-1 runtimes.

Deliverable

Added in Batch 3

Source · honesty

/runtime/admin-control-plane-service/ttl_examples.json

10 TTL evaluation examples · valid / near-expiry / just-expired / stale / not-applicable / unknown · prec-8 fail-safe documented

Contract-only · no TTL enforcer running · pairs with existing approval_examples.json

/runtime/feature-flags-service/phase_2b_plus_contract.json

Full 2b+ contract · delta_from_2b · 4 verification_modes · persistence_backend · cache_invalidation · policy_aware_sensitive_gating · rollout_visibility · 8-item deferred_matrix

No new runtime endpoint · artefact frozen for 2c migration parity

/runtime/feature-flags-service/cache_invalidation_contract.json

Channel ptt.ff.invalidate · key prefix ptt:ff: · 4 namespaces · 4 triggers · stampede protection strategy

NO cache in 2b+ · contract written for 2c Redis wiring

/runtime/feature-flags-service/jwt_verification_notes.json

5-priority resolution order · 4-mode matrix (verified / decode-only / dev-fallback / anonymous) · claim_expectation · security_bank

Decode-only runs in 2b+ · verified mode deferred to 2c (JWKS + aud=pty-feature-flags)

/runtime/feature-flags-service/persistence_backend_notes.json

Current file-backed state · planned Postgres schema (ff_flag / ff_tenant_override / ff_user_override / ff_audit) + Redis · 6-step 2c migration

No DB client · no alembic · no Redis in 2b+ — fully file-backed JSON

/planning/feature-flags-phase-2b-plus.html + /runtime/feature-flags-service/phase-2b-plus.html

Planning page (scope/non-scope/use cases/deferred) + runtime debug inspector (tabbed contract JSONs · 5 use-case cards · auto-rendered deferred matrix)

Read-only inspector · no endpoint calls · fetches 4 local contract JSONs

5 × Batch-1 runtimes

Tenant rollout card (tenant-zeroth · scope-tenant-only · FF candidate per surface) + hint guidance panel loaded from contract sources (not AI)

Contract-sourced · truncated strings · never hits Claude · appended before Honest Runtime Limits

Invariants preserved from Batch 1/2: contract-bound · no mutation path · no B write-back · no IA reshuffle. Every surface keeps its existing Honest Runtime Limits block unchanged; Batch 3 only appends a rollout/hint section above it.

Batch 4 addendum infra-backed readiness · contract artefacts + planning pages · non-implementation

Batch 4 is a readiness-documentation pass for Phase 2c. Zero endpoints added. Zero code changes to app.py or policy_engine.py. Zero DB/Redis/JWKS wiring. What Batch 4 ships is the conformable target that FF 2c / Admin 2c must build against, plus the 42-item FF checklist and the 28-item Admin checklist that function as the cutover acceptance gate.

Deliverable set

New artefacts

Honesty

A · JWT / JWKS readiness (FF)

jwks_integration_notes.json · jwt_claim_examples.json (10 fixtures) · verification_mode_matrix.json (17 rows)

documented · not wired · verified mode remains decode-only in 2b+

B · Persistence schema + parity (FF + Admin)

FF persistence_schema.json · FF cutover_parity_matrix.json · Admin persistence_schema.json · Admin approval_store_examples.json (6 fixtures)

target DDL · no migration run · no schema in Postgres · file-backed remains authoritative

C · Redis / cache invalidation (FF)

cache_runtime_notes.json · redis_channel_examples.json (6 pub/sub kinds)

no Redis client wired · channel name reserved but no publisher / subscriber exists

D · Parity / cutover readiness (FF + Admin)

FF parity_test_matrix.json (17 vectors) · FF cutover_readiness_checklist.json (42 items) · Admin cutover_readiness_notes.json (28 items)

0 vectors executed · 0 items READY · checklists are the Phase 2c acceptance gate

E · Planning + coherence (discoverability)

planning/feature-flags-batch-4-readiness.html · planning/admin-control-plane-batch-4-readiness.html · Ops-Portal strip · index-catalog / appendix-catalog / fulltext-index / fulltext-sources updates

no new main-console button · no mutation path · append-only

Invariants preserved: no B write-back · no mutation path · no new endpoints · no IA reshuffle. All prior Batch 1/2/3 surfaces untouched (except the minimal Ops-Portal strip append and this addendum). The 5 Batch-1 runtimes still carry their Batch-3 Tenant rollout · Hint guidance block; Batch 4 does not re-enter those files.