[Spec 027] Complete Console trusted publication and real frontend CI

[XnLemon]

What to build

Complete the user-operable Phase 1 trusted invocation loop in the production Glass 2.0 Console. The existing independently merged Console must become the repository-owned Console deployment, keep all comparison demos, use only public Gateway routes, and add the provider workflow for endpoint ownership verification and immutable Agent Release lifecycle. A user must be able to register an Agent Card, prove its endpoint, publish a trusted Release, discover and install it into one Workspace, invoke it through Gateway/Router, and inspect the resulting Invocation/Trace lineage without using SQL, direct Agent access, or mock production data.

The same slice must make frontend CI real: the repository frontend checks must discover the production Console and execute its typecheck, tests, and build. The Console remains Owner-only with one active Workspace in this phase; provider and owner credentials are explicit development-static configuration and are never persisted by the browser.

Acceptance criteria

• The production Glass 2.0 Console and its #/demo, #/demo/glass, #/demo/terminal, and #/demo/saas comparison routes are owned and built from the platform repository.
• The Console provides live Trusted Publication v1 operations for Endpoint Binding creation/read, Challenge issuance/completion, immutable Release creation/read, verification, publish, suspend, and revoke through public Gateway routes only.
• A newly registered Agent can complete Register -> Verify -> Publish -> Discover -> Install -> Invoke -> Record from the Console against a fresh platform environment, including one Runtime A -> Router -> Runtime B nested lineage.
• Installation selects only a published trusted Release; pre-acceptance, disabled, suspended, revoked, credential, unavailable endpoint, timeout, cancellation, and interrupted-stream outcomes remain distinct and never become fabricated success data.
• Browser configuration requires exact Gateway origin, provider/owner principals, one Workspace, and bearer credential values; no wildcard origin, localhost fallback, token trimming, local-storage credential persistence, retry, reconnect, alternate endpoint, or legacy publish fallback is added.
• The Console uses strict handwritten mappings of the active Agent Card, Trusted Publication, Workspace/Installation, Invocation/Result/Error, and Ledger contracts and rejects unknown or inconsistent response shapes.
• Focused frontend tests cover the trusted-publication state transitions, request construction, exact errors, JSON/SSE correlation, and secret absence; a browser-level fresh-environment acceptance proves the complete visible loop.
• Repository CI runs Console typecheck, tests, production build, and the browser acceptance rather than succeeding with no matched frontend project.
• Spec, plan, tasks, contract mapping, quickstart, operational documentation, independent Review, and convergence evidence are complete before merge.

Blocked by

None - can start immediately. The required backend contracts and acceptance are merged through PRs #53-#58.

[XnLemon]

Spec 027 is now drafted at https://github.com/NeKiro-project/NeKiro/blob/main/specs/027-console-trusted-publication/spec.md. Delivery is split into independent slices: Console contract client, trusted publication and release operations UI, fresh-environment frontend acceptance/CI, plus a separate backend issue for canonical Runtime B -> Router -> Runtime A lineage. Each implementation slice requires a pre-implementation Issue review and an independent post-implementation code review.

[XnLemon]

Spec 027 clarification is now reflected in the Console child Issue scopes. Slice B will keep the existing public contracts: provider/owner credentials and providerId are explicit configuration, and the owner reviews a handed-off Release ID via GET /v4/releases/{releaseId} before installing the exact Card version. The Console validates the returned installedReleaseId against that Release; it does not infer Release identity from Catalog publication or add a fallback API.

[XnLemon]

Spec 027 delivery evidence: the production Console is imported under apps/console and the standalone source remains NeKiro-project/NeKiro-Console. Root PR #62 contains the reverse Runtime B -> Router -> Runtime A acceptance and frontend/browser integration. Root CI run 30319275997 passed all 7 checks, including backend-acceptance and console-browser-acceptance. Console PRs #5/#6/#7 carry the reviewed API, operations UI, and browser slices; standalone browser CI runs 30254947242 and 30254944783 passed. Root frontend verification passed pnpm typecheck, pnpm test (36/36), pnpm build, git diff --check, Compose config, and secret/direct-route scans. The prior browser failure was caused by reversed internal-auth digest wiring and fixed in root commit 2d1b4c1; no runtime contract, retry, fallback, or alternate endpoint was added. Slice C and Slice D share root PR #62, so FR-017/T039 remains open until scopes are split or explicitly approved.

[XnLemon]

Slice D final delivery evidence (commit 3dad843):

• PR feat(console): isolate production browser acceptance #64 remains stacked on Slice C PR test(platform): isolate reverse cross-runtime acceptance #63 and is Console/CI/Spec-only; no Router, Control Plane, contract, database, direct Agent, or alternate endpoint changes.
• CI run 30329624757: all 8 checks passed, including frontend, go-quality, backend-acceptance, workspace-integration, runtime-samples-quality, compose-config, console-browser-acceptance, and Codecov.
• Local verification: pnpm test 41/41, pnpm typecheck, pnpm build, and git diff --check.
• The prior browser failure in run 30328793812 was diagnosed as the read-only Header status layer intercepting the Create Workspace control at the CI viewport. Commit 3dad843 adds pointer-events-none to that status layer; the fresh browser acceptance passed.
• Final independent review of 253c187..3dad843: 0 High / 0 Medium / 0 Low.
• Fallback delta: removed 1 implicit Agent-selection fallback, retained 0, added 0, net -1. Added fallback evidence: none.

The historical T005 ordering deviation remains recorded in Spec 027 and is not being rewritten as satisfied.

[XnLemon]

Spec 027 is complete. PR #65 merged the production Console, trusted publication operations, reverse Runtime B -> Router -> Runtime A acceptance, and real frontend CI; PR #70 merged the operation report. CI run 30401796416 and PR #70's CI run 30402965859 passed all required checks. The historical T005 ordering deviation remains recorded in specs/027-console-trusted-publication/tasks.md; the current accepted nested direction is B -> Router -> A as documented by the active plan and AGENTS.md.