Persona workspace gap analysis
Date: 2026-05-24
Local console audited at https://stella-ops.local after signing in with the local admin seed. The in-app browser extension was unavailable, so the route pass used terminal Playwright. The crawl covered 35 routes exposed by the sidebar, dashboard links, setup links, and discovered follow-on links; all 35 rendered.
Current finding
The original 35-route audit predated the Developer Services implementation. As of 2026-07-12, /developer/services is the first-class contributor workspace. Its personal projection now fails closed: missing ownership claims show an explicit configuration state without broad release/deployment/finding reads, canonical service aliases are deduplicated, neighboring names do not match by substring, and deployment-derived environments remain limited by the contributor’s allowed-environment claims. The remaining rows below distinguish shipped behavior from product follow-ups.
Page and functionality changes to consider
| Area | Current pages observed | Change needed |
|---|---|---|
| Navigation | /, sidebar sections Developer, Release Control, Security, Operations, Settings | /developer/services now exposes a visible Developer Services entry for the developer service-update scope bundle. The local demo developer seed now materializes service/environment ABAC, and Release Orchestrator enforces it for direct updates and developer approval requests. |
| Dashboard | / | Add role-sensitive dashboard lenses: CTO compliance/deployed-as-expected, DevOps approval/deployment health, security-manager risk/finding queue, developer owned-service image candidates and blocked updates. |
| Environments/topology | /environments/overview, /setup/topology/environments | Show service ownership and allowed developer update environments. DevOps still owns topology; developers should see only environments they can target. |
| Deployments | /releases/deployments | Developer context filters are implemented for service, initiating developer, source type, and digest, so DevOps can separate developer update requests from operator promotions. |
| Releases | /releases, /releases/bundles | Add a developer-oriented image candidate path: select owned service, choose CI/registry digest, see scan/policy status, update allowed env or request promotion. Artifact successor suggestions are implemented for non-draft release image changes. |
| Approvals | /releases/approvals | Source labels are implemented for developer service updates, DevOps promotions, security reviews, and policy gates. |
| Policy | /ops/policy/packs | Policy management stays with DevOps/security, while Developer Services now exposes read-only “why blocked” explanations and scoped policy simulation links. |
| Security | /security/images, /triage/artifacts, /security/risk, /security/supply-chain-data | Developer Services now links blocked updates to scoped findings by release/service and summarizes critical/high/reachable finding context without exposing security-manager actions. |
| Advisory/integration health | /security/advisory-sources, /setup/integrations, /setup/integrations/advisory-vex-sources/* | Keep ownership with DevOps/security. Developer pages should show stale-feed impact as a blocker reason, not source administration controls. |
| Identity and access | /setup/identity-access | User editing now supports role/service-release-contributor and ABAC editors for service IDs, repositories/image namespaces, allowed environments, environment ceiling, and direct-update policy. The form warns on broad mixed grants. The tenant-wide release environment allow-list is implemented in Platform Setup Defaults & Guardrails. |
| Evidence and audit | /evidence, /ops/operations/audit, /evidence/audit-log | Add event types for developer image update requested, developer direct update executed, approval routed, approval granted, and update blocked. Evidence should link to the exact service, digest, environment, policy result, and actor. |
| Assurance/CTO | /assurance, dashboard compliance cards | Add CTO-facing “deployed as supposed” matrix: intended service version/digest, actual environment digest, policy baseline, open exceptions, last evidence seal, compliance-pack status. |
| Operations | /ops/operations, /ops/operations/jobengine, /ops/operations/doctor, /ops/scanner-ops | Keep operational control with DevOps, but expose read-only run progress and failure reason to the developer who initiated an allowed update/request. |
Functional requirements implied by developer users
- Service ownership model: map users/groups to service IDs, repositories, and image namespaces.
- Environment update policy: record whether a developer can update directly, request approval only, or has no access per environment.
- Candidate image ingestion: show CI/registry digests for owned services, not only raw scans or release bundles.
- Policy simulation before update: show PASS/WARN/BLOCK for the selected digest and environment.
- Approval routing: route blocked or approval-required updates to DevOps, security manager, or policy approver based on the failing gate.
- Evidence model: every developer update/request must link actor, service, source digest, target environment, policy result, approval trail, and deployment result.
- RBAC/ABAC: developer self-service must use scoped claims, not broad admin/operator grants.
Coverage plan
Implementation is tracked in docs/implplan/SPRINT_20260524_002_Web_developer_services_gap.md, artifact-derived release versioning is tracked in docs/implplan/SPRINT_20260524_005_ReleaseOrchestrator_artifact_update_versioning.md, and persisted admin release environment limits are tracked in docs/implplan/SPRINT_20260524_007_ReleaseOrchestrator_release_environment_limit_admin.md. The current slice adds /developer/services, sidebar navigation, dashboard deep links, live release/deployment/finding aggregation, a digest-first direct update button, a pasted-digest approval request path for newly built images, Authority demo developer ABAC seed, Router signed ABAC claim propagation, Release Orchestrator developer ABAC enforcement, a persisted developer update approval request object, a successor-release suggestion path when a new digest updates a component in a non-draft release, Platform Setup Defaults & Guardrails for tenant release environment limits, Identity & Access ABAC editing for service contributors, developer-focused security/policy explanations, and cross-page request/deployment labeling.
Product framing
Use this user language in page titles, empty states, and quick links:
- CTO: “deployed as expected”, “compliance posture”, “evidence”, “exceptions”.
- DevOps: “topology”, “promotion path”, “deployment”, “approval”, “rollback”.
- Security manager: “findings”, “risk”, “reachability”, “VEX”, “exception”.
- Developer: “my services”, “candidate image”, “update environment”, “request promotion”, “why blocked”.