Service Admin capture manifest and refresh guide

This is the canonical capture record. Admin bundles an exported copy for offline help.

The later newcomer verification includes a visible Echo detail capture and a verified detail-page stop/start sequence. The failures below remain historical evidence; they do not describe that later successful browser visit.

Intended capture	Route/state	Environment	Result
Dashboard overview	/, task-owned proxy	Core 3307d61787918d6d6dd195facfb808e2c2c0c9a9; Admin 5823f1b; 1440×1024; 2026-09-14	Blocked: headless page was blank
Services overview	/services, task-owned proxy	same	Blocked: headless page was blank
Help Center overview	/help-center, task-owned proxy	same	Blocked: headless page was blank

15 September 2026 refresh attempts

The initial Core issue worktree was based on 8d0201de3e8ebaf699f720a135f2110159cda99a; the intended Service Admin source was f5d7ea5012564eb6e470e12268752fe9efa9fd1f (the source later merged as Admin e3cb1ca192cd3719b34eb8cded895197746a4bac). Its first owned proof environment selected the catalogued @serviceadmin artifact 2026.8.31-f015b44, which could not prove that the current source Admin was being rendered. It also started node-sample-service, although that fixture's source policy is manifest-only. The generated gate correctly stopped the attempt with canonical_service_state_mismatch; no screenshots were accepted.

The bounded proof-generator repair on Core 2e49fdf keeps the sample disabled only in the copied proof inventory, disables the packaged Admin only when a validated --source-admin-root is supplied, and records an external source Vite command with its required proxy target. It also generates an explicit --runtime-port for dynamic-worktree verification while leaving canonical verifier defaults unchanged. The focused demo-instance suite passed 43 tests before this final flag-only correction; the flag regression itself passed.

A fresh owned proof, 1281-operator-captures-fresh-20260916, used Core 4741393df121a596831f0d1ad5d4398ff748b017, runtime http://127.0.0.1:18100, and source Admin Vite at http://127.0.0.1:18102/. Its first-run step completed, but the generated recycle still ended non-zero as canonical_verification_failed: runtime and Admin port checks plus the operator MCP connection, discovery, and representative-read checks all failed. The source Vite and Core proof services were then stopped through their verified owned processes and generated cleanup; the retained proof tree and logs remain available for diagnosis. No browser screenshots are claimed, and no blank artifacts are part of this documentation.

The follow-up diagnosis found that the recycle wrapper omitted the selected runtime and Admin ports when calling the verifier, which made it revert to canonical defaults even though the dynamic URLs were supplied. Core 6c0d05e forwards the explicitly parsed ports and has regression coverage for both dynamic and canonical values. No fresh runtime was started after that repair, so it does not establish a canonical-verifier pass or an all-route capture result. No credentials, secret values, or raw logs were captured.

16 September 2026 post-PR #1290 capture attempt

Core PR #1290 merged as 5172e802dd85ad705004c460ed2190fff8fe7dae; this fresh owned attempt executed the exact validated PR source 31ebe19ac8aff070c37fe2abc4e78b6e85c8c519 with Service Admin source e3cb1ca192cd3719b34eb8cded895197746a4bac. Proof ID 1281-operator-captures-post1290-20260916 allocated Runtime http://127.0.0.1:18100 and source Service Admin http://127.0.0.1:18101/. The generated gate reported healthy, and the generated canonical verifier passed, including runtime, source-Admin, operator-MCP, and service-state checks.

At a 1440×1024 viewport, the real browser stayed on its loading skeleton for more than 30 seconds at /, /services, and /help-center. Each same-origin API was independently reachable through source Admin (/api/dashboard and /api/services both returned HTTP 200), but no route rendered readable operator content and no browser error was emitted. The initial files were rejected as invalid skeleton screenshots and removed; this refresh publishes no images. The result is therefore Blocked for all three overview captures, owned by Core #1281. The next action is a focused source-Admin browser-load diagnosis that explains why the UI remains pending despite its healthy same-origin API proxy, followed by a new isolated proof and inspected captures. The owned runtime and source Vite process were stopped; the proof summary, cleanup receipt, and logs remain under .demo-logs/worktree-proof/1281-operator-captures-post1290-20260916/.

18 September 2026 current-source proof

Admin repair PR #623 is merged. A fresh isolated proof used Core 66e98e1d30458bef1bcc09fd399859413c66a2fa and current Admin c48f8d89b9eb0bc11b94b123acf68d74f0e3ac5d at a 1512×982 viewport. The generated runtime gate was healthy. The read-only Playwright tour then passed all 40 static authenticated destinations without invoking reveal, edit, reset, lifecycle, or record-specific actions.

The Services, Archive Utility Provider overview, and Help Center frames were visually inspected in ignored review storage. No token, credential, raw log, filesystem path, or external-link column was visible in those frames. The Dashboard frame was rejected because it displayed live allocation and generation details. Therefore no images are published by this record and the public dashboard-tour requirement remains blocked pending a real, public-safe Dashboard state or an authorised redaction policy. This is UI evidence only; it is not a GA, security-review, or broad acceptance claim.

18 September 2026 published approved frames

A fresh source-Admin capture used Core 61fd352f38b876ff008fc6246b2dc8ddd6713ce2 with Admin c48f8d89b9eb0bc11b94b123acf68d74f0e3ac5d at 1512×982. The full run audited all 40 static authenticated destinations and captured the four reviewed routes. Password controls were masked by Playwright before each PNG write.

The Services, Archive Utility Provider overview, and Help Center images were visually reviewed and copied by the runner into docs/static/img/service-admin-tour/; the UI guide embeds those three assets. The Dashboard PNG remains unpublished in this historical record because it was captured before the non-password policy proposed by Core #1322 existed. That policy defines the fail-closed dashboard-public-safe-v1 boundary: it masks every Dashboard value except the static Dashboard and Runtime health labels, records policy activation in the receipt, and refuses to promote the frame unless the exact policy identifier is selected. A fresh clean-environment capture and independent visual review remain required; no Dashboard image is published by this record. This capture proves rendered UI routes only; it is not a GA, security-review, or broad runtime-acceptance claim.

27 September 2026 recovered direct capture packet

The earlier truncated Dashboard evidence comment in #1322 is superseded for traceability by this later direct packet; its missing original candidate is not reconstructed. The verified Windows pair report records Core d0f68e3fc47b0bebc22a0cb55bf63c672b589637, merged with an identical complete tree as 72148b5009cca15db11aa1bffb0f1a261e655af3. It used released Admin 2026.8.31-f015b44 and Broker 2026.8.31-f340883, with both upstream artifact checksums verified, on Windows 11 Pro 10.0.26200 x86_64 / Node 22.23.2. The report retains browser versions, owned cleanup and the paired journey.

The actual paired archive is 1,845,521 bytes with SHA-256 3e5389f65dd89227d39d435e6383e9d07b6566608a6cb291a40f5dd24b2d364e. The retained local archive was rehashed during this reconciliation and matches the downloaded attachment verification. Inside a.zip, screenshots/ops-tour/capture-receipt.json records the dark 1512×982 capture from 2026-09-21T18:31:04.479Z to 18:32:15.721Z: all 40 routes passed, four frames captured, no audit failures, and ok=true.

Capture	Archive path inside a.zip	Direct observation and limit
Dashboard /	screenshots/ops-tour/dashboard.png	Rendered with active dashboard-public-safe-v1; operational content redacted. Review-only, not published.
Services /services	screenshots/ops-tour/services.png	Readable service table; stopped Node Sample/OpenObserve warnings remain visible. Does not establish all-services health.
Archive /services/%40archive	screenshots/ops-tour/archive-overview.png	Actual provider overview; local filesystem values masked. No record-specific action acceptance inferred.
Help Center /help-center	screenshots/ops-tour/help-center.png	Readable local documentation and navigation.

All four retained images were visually inspected during reconciliation; none is a blank, setup or skeleton frame. Dashboard image SHA-256 is cf6f62ad74a0a2a0749e66386236d60db5aefb02f2347eea61108aa3c082b08f. The receipt retains password/local-path masking, the two allowed Dashboard content labels, promotion=review-only and promotedAssets=[]. No new image or public Dashboard asset is introduced here. Same-operator inspection is not the independent review required for public promotion.

These frames provide later direct evidence for the four tour states at 1512×982. The historical 1440×1024 failures above remain unchanged. Admin #622 still has completed its literal 1440×1024 source replay of /, /services and /help-center; the new evidence record below retains its publication limits. Core #1281 remains open until its complete acceptance mapping and this documentation change pass review and required checks. No publication, macOS evidence, independent approval or GA conclusion is inferred.

Refresh captures

Create issue worktrees from develop in Core and Service Admin. Run Core npm ci, then npm run demo:worktree-proof -- --id=<issue>. Start source Service Admin on its allocated port with SERVICE_LASSO_RUNTIME_PROXY_TARGET set to the allocated Core runtime URL and VITE_SERVICE_LASSO_API_BASE_URL set to the allocated source-Admin URL. The latter keeps browser API requests same-origin so the Vite proxy can retain the loopback client identity. Run the generated gate and verify commands, stop on any non-zero result, and record its classification. Do not change product behaviour just to make a capture pass.

Reusable Playwright tour

Install the browser once in the clean Core worktree, then run the tour against the intended live Service Admin root:

npx playwright install chromium
npm run capture:service-admin-tour -- --url=http://127.0.0.1:17700/

The tour uses an isolated dark browser context at 1512×982 with device scale factor 1. On a loopback target only, it selects the password-free local-root role in that temporary context; it never reads or enters a token or password. It checks that actual UI has rendered before capturing these read-only routes:

Asset name	Route	Required state
dashboard.png	/	Dashboard and Runtime health visible; public promotion additionally requires dashboard-public-safe-v1
services.png	/services	Services table rendered; the Links column is hidden
archive-overview.png	/services/%40archive	Archive Utility Provider Overview visible
help-center.png	/help-center	Help Center and local-docs notice visible

Before it captures, the command visits all 40 current static read-only authenticated destinations, including the Services, Operations, Secrets Broker, Settings, and workspace routes. Redirect destinations are checked at their resolved route. Dynamic record URLs and actions that need a specific record, reveal a value, or mutate state are not invented or invoked by the suite.

The command saves a timestamped review set below .tmp/service-admin-tour/ and writes a metadata-only capture-receipt.json listing the requested and resolved audit routes plus stable codes for any routes that could not render. It completes the selected audit inventory before failing, and it creates no screenshots if even one audited destination fails. Pass --output-dir when a different ignored review directory is needed. It refuses to write directly to docs/static, so an inspected image cannot accidentally become public content. It also fails before any screenshot if it sees first-run credentials, authentication-required, unavailable, or skeleton states. It does not sign in, reveal data, modify lifecycle state, or invoke any operator action. Before every PNG write it uses Playwright's native screenshot mask for password fields and fields marked with password autocomplete metadata. The receipt records that this protection was active. This narrowly protects entered password values; it does not make other operational data (such as a live port, allocation, identifier, or log value) safe to publish. Those frames still need visual review and an explicit publication decision.

If an execution environment has a short command timeout, use four bounded audit passes, then one capture-only pass. Together these cover the same inventory:

1..4 | ForEach-Object {
  $start = ($_ - 1) * 10
  npm run capture:service-admin-tour -- --url=http://127.0.0.1:17700/ --audit-only --audit-start=$start --audit-limit=10
}
npm run capture:service-admin-tour -- --url=http://127.0.0.1:17700/ --skip-audit

The matching --capture-start and --capture-limit options can bound a capture to one reviewed route where a command runner has a short timeout. They never widen the capture scope beyond the four listed in this manifest.

Every normal run regenerates the public guide assets in the current issue branch. The runner copies the approved Services, Archive Utility Provider, and Help Center captures to docs/static/img/service-admin-tour/ only after the selected audit and every selected capture pass:

npm run capture:service-admin-tour -- --url=http://127.0.0.1:17700/

Dashboard is review-only by default. To make it eligible for public promotion, use the exact dashboard-public-safe-v1 policy against a clean owned environment after the full audit:

npm run capture:service-admin-tour -- --url=http://127.0.0.1:17700/ --dashboard-public-policy=dashboard-public-safe-v1

The runner replaces every Dashboard text value except the static Dashboard and Runtime health labels with [REDACTED] before it writes the PNG. Inspect the resulting PNG and receipt independently for prohibited content before committing. Commit the regenerated assets and the updated manifest through the normal docs PR. A successful capture run is UI evidence for its four routes only; it is not a GA, security-review, or broad runtime-acceptance claim.

Replace this record with verified, readable browser captures only after the generated runtime gate and verifier both succeed.

Literal 1440×1024 source replay (2026-09-27)

The owned replay used Core cdb877a16e005e5e9e70214192585d0cdd7ec6c3 and source Admin a3c972e881a1c781f7a7cc3d411e3e0b02981ab8. Its receipt records 2026-09-27T01:37:22.457Z–01:38:29.306Z, 40 read-only route audits, three PNGs at exactly 1440×1024 and ok=true. Dashboard, Services and Help Center were individually inspected. Dashboard uses the canonical redaction policy; password controls and local paths are masked. Services renders its table, with horizontal clipping at this viewport retained as a layout limitation. This proves rendered loading completion for these source routes, not every layout or interaction contract.

The owned runtime gate and canonical verifier passed; supported cleanup settled all six owned entries and the separately owned source server stopped. Earlier entry-wait and privacy-toggle harness attempts remain retained and are not successful evidence. The successful inspected packet contains only the three PNGs, receipt.json and REPORT.md: 543,390 bytes, SHA-256 58934b7fb8c8c849ab52853aed4598df32904b92cd1defba68e7c0bc88df7d13. The versioned evidence archive retains that exact packet in source history. It is source evidence, not a published documentation asset or released-package acceptance. The issue receipt records the replay and limits. Neither issue is closed by this record; it provides no independent GA approval or released-package acceptance.