Cross-Runtime Integration 13 · Policy-first · Eval-second · integration surface between Admin Phase 2a + FF Phase 2a+

Phase statement ข้อกำหนดเฟส

Phase 2a + 2a+ of Admin and Feature Flags respectively have produced two runnable decision services. Each contract is clear in isolation but operators cannot see how they compose. This phase delivers a single page that wires both services together in the exact order they should be consumed — policy-first, then eval — with honest trace and honest deferred items. It does not open new runtime capability; it makes the existing capability legible.

Route rationale เหตุผลของ path

Per docs/planning/ia-governance.json:

• · /runtime/* is A-owned · debug / scaffolding / integration surfaces belong here → chose /runtime/cross-runtime-integration/.
• · /planning/* is A-owned · RFC / design / rationale belongs here → this page lives at /planning/cross-runtime-integration.html.
• · Dashboard is a reserved naming term (hard rule #5) — this page uses "Integration Demo", not Dashboard.
• · Main console stays at 6 top-level buttons (soft cap) → discoverability for this demo is via Index Portal + back-links from the 3 sibling surfaces.

IA rationale เหตุผลเชิง IA

The demo is a third-party consumer of the two services, not a fourth service. It intentionally stays at the "preview / debug / scaffolding" tier of the IA owner matrix (Runtime Phase Pack) and does not promote to Admin Portal, App, or a new sub-portal. When a production surface eventually wants to consume both services, the orchestration rules shown here (policy-first · eval-second · short-circuit on deny) become the reference sequence for middleware.

A-owned vs B-owned boundary เส้นแบ่ง ownership

No B-owned file is written or reinterpreted by this phase. Cross-tenant write workflows are explicitly out of scope.

Input files ไฟล์ที่ demo ใช้

Orchestration sequence ลำดับการประสานงาน

// Browser page · policy-first · eval-second
sequence:
  browser → registry.json           // step 1 · local lookup
  browser → policy_service step 2
    POST /api/policy/sensitive/check   // sensitive flag path
      OR
    GET  /api/policy/access/check      // requires_approval (not sensitive) path
  policy_service → browser
    response: {decision, reasons, required_approvers, approval_matrix_row, trace}
  IF decision != allow → SHORT-CIRCUIT · skip step 3
  browser → flags_service    step 3 (only if allowed)
    GET /api/flags/eval?key={flag_key}&user={actor_user_id}&…
  flags_service → browser
    response: {value, source, stage, bucket, trace, evaluator_version}
  browser combines into single view step 4
    {policy_gate_status, can_proceed_to_eval, flag_eval_status, policy_result, flag_result, combined_trace, honest_limits}

Status labeling การติดป้ายสถานะ

• · Runtime surface /runtime/cross-runtime-integration/ → Live (demo · local/dev only)
• · Planning surface /planning/cross-runtime-integration.html → Live (v1 · this page)
• · Each deferred item is explicitly labeled deferred — see the deferred matrix below and in the demo page itself
• · No "production-ready" · "fully integrated" · "completed end-to-end" wording appears anywhere

Discoverability impact ผลกระทบต่อ discoverability

• · New Index Portal entry idx-runtime-cross-integration at 04.04.00.00 (runtime tab)
• · New planning entry idx-planning-cross-integration at 03.13.00.00
• · 2 appendix entries (README + demo_contract) in runtime_artefacts group
• · Back-links from /runtime/feature-flags-service/service.html, /runtime/admin-control-plane-service/service.html, and this planning page
• · Fulltext index rebuilt to include the new surfaces
• · No new main-console button (IA soft cap preserved)
• · No new Operations Portal button (6 Ops sub-entries remain stable)

Deferred matrix รายการที่ยังไม่ทำ

Definition of Done · this demo only เกณฑ์จบของ demo นี้เท่านั้น

What this demo is NOT สิ่งที่ demo นี้ไม่ใช่