Milestone 4.D.0 — Canonical IBEX Console Foundation & Shell MigrationCopy Anchor Link

Status: in-progress. The canonical services/console foundation scaffold and deterministic preview boundary are implemented and verified; live authentication, backend contracts, deployment, and compatibility cutover remain open. Outcome: services/console is the canonical operator application boundary, the existing product shell is transplanted with deterministic preview/test separation, and services/dashboard remains a compatibility-only shell with an explicit retirement gate. Track: Track D — Operator Capability Slices Dependencies: P0 + P1 first; then D0 may proceed in parallel with P6-bootstrap. The topology/runtime, identity boundary, ownership, environment, data-classification, and shell-retirement decisions remain specification inputs. Estimated effort: 4 weeks

PurposeCopy Anchor Link

Create the application boundary and quality gates needed for real operator capabilities without coupling authenticated product release to the public documentation site or leaving two production-intended dashboard implementations. This milestone is the foundation for D1; it does not claim that D1 data contracts or live operator behavior already exist.

ScopeCopy Anchor Link

• Add the canonical services/console workspace package and preserve the mock's visual/product baseline while transplanting its shell and route structure.
• Establish server-only API/DAL boundaries, typed response/error handling, route-level loading/error/not-found states, and explicit preview/test/production modes.
• Make fixture adapters deterministic and confined to preview/test boundaries; label preview data and prevent preview credentials or mutations from reaching production paths.
• Remove or isolate browser-local simulated sessions, secret-like persistence, nondeterministic rendering, and placeholder internal navigation from the transplanted foundation.
• Record the topology/environment matrix, API ownership map, data-classification decision, visual baseline inventory, and compatibility-shell retirement criteria.

Non-goalsCopy Anchor Link

• No claim that login, organization context, Overview, platform health, or SSE is live; those are D1 deliverables.
• No full Explore, Trace Inspector, sessions, incidents, actions, billing, or other D2–D6 production domain integration.
• No redesign of the mock product, public web/ documentation site, or backend service ownership.
• No retirement of services/dashboard until its compatibility and cutover evidence meet the recorded gate.

DependenciesCopy Anchor Link

P0 + P1 are D0 entry contracts. D0 and P6-bootstrap may proceed in parallel after those contracts are available. P6-slice-certification is not implied by D0, and D0 does not waive authorization, tenant, privacy, deployment, or assurance gates.

DeliverablesCopy Anchor Link

1. A buildable services/console package registered in the workspace with the transplanted shell, shared styles/assets, and route boundaries. Delivered as the first implementation slice: the package builds, typechecks, lints, and has a passing deterministic test suite.
2. A server-only transport/DAL boundary with runtime response parsing, stable error classification, request/deadline handling, and no arbitrary component-level upstream fetch.
3. Separate preview/test/production data modes, deterministic browser fixtures, a visible preview-data indicator, and proof that fixture adapters cannot be selected by the production mode. Delivered for the current shell: preview/test gating and production fail-closed behavior are covered by unit tests; browser-level proof remains open.
4. A visual and accessibility baseline inventory for stable shell/state surfaces, plus a lint, typecheck, build, and deterministic test baseline.
5. Migration documentation covering operator origin/environment policy, contract ownership, data classification, compatibility behavior, and the services/dashboard retirement gate.

Acceptance evidenceCopy Anchor Link

• Workspace install, lint, typecheck, deterministic tests, visual/accessibility checks, and production build artifacts for console are attached to the milestone record.
• A browser test demonstrates that preview fixtures are available only in preview/test mode, are visibly labeled, and cannot be reached with production session configuration.
• A route and dependency inventory demonstrates that authenticated operator routes are in services/console, while public documentation remains in web/ and services/dashboard is compatibility-only.
• Security review evidence covers removal/isolation of local session or secret persistence, server/client boundaries, cache defaults, safe error handling, and hostile-content rendering policy.
• The compatibility shell's tested origin/SSE behavior is recorded, and cutover/rollback steps plus the retirement gate are reproducible. No retirement is claimed by this milestone.

Completion ruleCopy Anchor Link

Complete only when the canonical package builds and passes its deterministic quality gates, the production path has no fixture or browser-simulated data source, the migration decisions and rollback are recorded, and compatibility evidence shows that services/dashboard can remain safely available during cutover. The current scaffold satisfies only the package-quality and explicit fixture-boundary portions; a roadmap page or transplanted UI alone is not completion evidence.

Implementation sequenceCopy Anchor Link

1. Confirm the topology/origin, ownership, data-classification, environment, and shell-retirement decisions.
2. Seed services/console and transplant the shell/product baseline without connecting real production APIs.
3. Establish deterministic preview/test boundaries, server-only transport/DAL conventions, route boundaries, and secure browser behavior.
4. Add visual, accessibility, lint, typecheck, build, and browser compatibility evidence; fix issues without weakening checks.
5. Publish the cutover/rollback runbook and hand the canonical foundation to 4.D.1. D1 then connects real context, Overview, health, and SSE; D2 remains metadata-first and evidence-gated.

Open questionsCopy Anchor Link

• What are the approved production hostnames and exact same-origin or cross-origin cookie/CSRF/SSE rules?
• Which backend service owns each D1 context, Overview, health, and event contract, and when is the AuthService-owned session path available in shared environments?
• What exact compatibility duration and parity signals permit retirement of services/dashboard?
• Which visual baseline tolerances and supported-browser matrix are release requirements?

Findings addressedCopy Anchor Link

F4-001, F4-002, F4-008, F4-012, F4-014, F4-035, and the console migration facts recorded in the Phase 4 findings register.

Exit checklistCopy Anchor Link

• services/console is the canonical workspace application boundary.
• Preview/test fixtures are isolated, labeled, deterministic, and impossible on the production data path.
• Shell, contract, security, accessibility, and build evidence is attached.
• services/dashboard compatibility behavior and retirement gate are documented; no premature retirement is claimed.
• D1 entry contract is explicit: real context, Overview, platform health, and SSE, with no fixture production path.