Archive completed sprints 001-005 and update Sprint 007 task statuses
Archive 5 fully-done sprints to docs-archived/implplan/: - 001: Setup/admin operator journey audit - 002: Release confidence operator journey audit - 003: Identity/trust operator journey audit - 004: Integrations operator journey audit - 005: Release create contract alignment Update Sprint 007: mark TASK 1-10, 006b, 007a-c as DONE (all implemented and committed). Only TASK-011 (documentation update) remains TODO. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,80 @@
|
||||
# Sprint 20260315_001 - Platform Setup Administration Operator Journey Audit
|
||||
|
||||
## Topic & Scope
|
||||
- Use Stella Ops as a first-time platform administrator setting up the product for real organizational use after installation.
|
||||
- Drive end-user admin journeys first: identity and access, tenant and branding, notifications administration, trust/signing administration, setup integrations management, and adjacent setup surfaces that an operator would use during onboarding.
|
||||
- Treat retained Playwright as evidence and regression coverage, not as a substitute for discovery; every newly discovered manual setup/admin defect must become retained coverage afterward.
|
||||
- Group fixes by root cause so the iteration closes full setup/admin behavior slices instead of isolated page patches.
|
||||
- Working directory: `.`.
|
||||
- Expected evidence: operator journey notes, retained Playwright additions or hardening, grouped defect analysis, focused tests where code changes land, rebuilt-stack retest results, and live aggregate evidence.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on local commit `2661bfefa` as the closed baseline from scratch iteration 013.
|
||||
- Safe parallelism: avoid environment resets while live setup/admin journeys are running because the stack is shared.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `AGENTS.md`
|
||||
- `docs/INSTALL_GUIDE.md`
|
||||
- `docs/dev/DEV_ENVIRONMENT_SETUP.md`
|
||||
- `docs/qa/feature-checks/FLOW.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### PLATFORM-SETUP-ADMIN-001 - Define and execute setup/admin operator journeys
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: QA, Product Manager
|
||||
Task description:
|
||||
- Act as a platform administrator onboarding Stella Ops for real use. Cover identity and access management, tenant and branding changes, notification administration, trust/signing inventory and workflows, setup integrations management, and any adjacent setup surfaces encountered during the journey.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The primary setup/admin operator journeys are explicitly listed before fixes begin.
|
||||
- [x] Playwright is used to execute those journeys as an operator would, not only as route sweeps.
|
||||
- [x] Every broken route, page-load, data-load, validation rule, or action encountered on the operator path is recorded before any fix starts.
|
||||
|
||||
### PLATFORM-SETUP-ADMIN-002 - Convert newly discovered admin steps into retained coverage
|
||||
Status: DONE
|
||||
Dependency: PLATFORM-SETUP-ADMIN-001
|
||||
Owners: QA, Test Automation
|
||||
Task description:
|
||||
- Add or deepen retained Playwright coverage for every newly discovered setup/admin step so future iterations recheck the same operator behavior automatically.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Every newly discovered operator/admin step is mapped to retained Playwright coverage or an explicit backlog gap.
|
||||
- [x] Retained coverage additions are organized by user journey, not only by route.
|
||||
- [x] The next aggregate run would exercise the newly discovered setup/admin path automatically.
|
||||
|
||||
### PLATFORM-SETUP-ADMIN-003 - Repair grouped setup/admin defects and retest
|
||||
Status: DONE
|
||||
Dependency: PLATFORM-SETUP-ADMIN-002
|
||||
Owners: 3rd line support, Architect, Developer
|
||||
Task description:
|
||||
- Diagnose the grouped failures exposed by the setup/admin journey, choose the clean product/architecture-conformant fix, implement it, add retained Playwright coverage for the new behavior when needed, and rerun the affected journeys plus the aggregate audit before committing.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Root causes are recorded for the grouped failures.
|
||||
- [x] Fixes land with focused regression coverage and retained Playwright scenario updates where practical.
|
||||
- [x] The live stack is retested through the same setup/admin journeys before the iteration commit.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-15 | Sprint created immediately after local commit `2661bfefa` closed the release-confidence operator iteration cleanly at `25/25` suites with `0` retries. | QA |
|
||||
| 2026-03-15 | Defined the setup/admin operator path as: identity and access (`/setup/identity-access` users, roles, tenants), tenant and branding (`/setup/tenant-branding`), notifications administration (`/setup/notifications/channels/new`, `/setup/notifications/rules/new`), trust and signing (`/setup/trust-signing/*`), setup integrations management, direct docs navigation, global search from the operator shell, and security reports embedding under the setup-adjacent admin workflow. | QA |
|
||||
| 2026-03-15 | Discovery before fixes found one real setup/admin defect and one retained-coverage defect. Real product defect: canonical `/setup/notifications/channels/new` did not enter create mode and the UI allowed empty `secretRef` even though the notifier contract requires a non-empty secret reference. Retained defect: the user-reported trust/admin probe misclassified `Signing Keys` and `Audit Log` as blank because it used the wrong selectors and did not wait for routed tab resolution. | QA |
|
||||
| 2026-03-15 | Repaired notifications onboarding in `channel-management.component.ts`, added focused Angular regression coverage in `channel-management.component.spec.ts`, added the spec file to `tsconfig.spec.features.json`, and deepened `live-setup-admin-action-sweep.mjs` so setup/admin retained coverage now proves routed channel creation, required `secretRef`, rule-channel visibility, and cleanup. | Developer |
|
||||
| 2026-03-15 | Hardened `live-user-reported-admin-trust-check.mjs` to wait for tab-specific resolution, inspect the real key/audit selectors used by trust management, and prove a successful valid user-create path in addition to invalid-email rejection. | Test Automation |
|
||||
| 2026-03-15 | Verification: focused Angular `channel-management.component.spec.ts` passed `71/71`; `npm run build` passed; `live-setup-admin-action-sweep.mjs` passed with `failedActionCount=0` and `runtimeIssueCount=0`; `live-user-reported-admin-trust-check.mjs` passed with `failedCheckCount=0`, including valid user creation plus role and tenant creation persistence. | QA |
|
||||
| 2026-03-15 | Direct live reruns of the adjacent setup/admin probes confirmed the remaining aggregate noise was not a reproducible product defect: `live-user-reported-admin-trust-check.mjs` resolved all trust tabs cleanly, and `live-setup-topology-action-sweep.mjs` finished `failedActionCount=0` with `runtimeIssueCount=0`. | QA |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: this iteration prioritizes first-time administrator behavior over broad route counts.
|
||||
- Risk: some setup/admin surfaces are currently covered only through shared checks, so behavior gaps may still exist even when route and aggregate summaries are green.
|
||||
- Root cause: the notifications channel create route advertised a canonical create page, but the component ignored route data and stayed in list mode; the same surface also presented `Secret Reference` as optional even though the notifier domain requires it.
|
||||
- Root cause: the retained trust/admin probe used generic selectors (`.key-dashboard__loading`, `.trust-audit-log__empty`) that do not exist in the live components and only waited a fixed 1.5 seconds after tab routing, producing false failures on `Signing Keys` and `Audit Log`.
|
||||
- Decision: retained Playwright checks for setup/admin surfaces must wait for route-specific resolution selectors rather than infer success from headings or generic shell-level alerts.
|
||||
- Investigation note: direct reruns on the live stack showed `Certificates`, `Audit Log`, and the adjacent setup topology journey all converging cleanly, so this iteration did not justify a product-side trust/topology change beyond the retained-check hardening already captured above.
|
||||
|
||||
## Next Checkpoints
|
||||
- Let the in-flight `live-full-core-audit.mjs` consume the hardened user-reported admin/trust script and confirm the broader aggregate remains clean.
|
||||
- Start the next operator-first iteration from a fresh user journey outside setup/admin, carrying forward every newly retained step as regression coverage.
|
||||
@@ -0,0 +1,76 @@
|
||||
# Sprint 20260315_002 - Platform Release Confidence Operator Journey Audit
|
||||
|
||||
## Topic & Scope
|
||||
- Use Stella Ops as a release operator trying to gain confidence in a production promotion decision.
|
||||
- Drive the release-control journey end to end: mission control to approvals, promotions, deployments, release health, hotfixes, release evidence, and the adjacent security/evidence pivots a release operator actually uses while deciding.
|
||||
- Treat Playwright as retained evidence only after manual discovery. Every newly discovered release-confidence step or defect becomes retained coverage before the sprint closes.
|
||||
- Group fixes by root cause so the iteration closes whole release-confidence behavior slices, not isolated page patches.
|
||||
- Working directory: `.`.
|
||||
- Expected evidence: operator journey notes, retained Playwright additions, grouped defect analysis, focused regression tests where code changes land, rebuilt-stack retest results, and live journey evidence.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on local commit `4a5185121` as the closed baseline from the setup/admin operator journey.
|
||||
- Safe parallelism: avoid environment resets while the live release-confidence journey is being exercised because releases, approvals, and evidence surfaces share the same stack state.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `AGENTS.md`
|
||||
- `docs/INSTALL_GUIDE.md`
|
||||
- `docs/dev/DEV_ENVIRONMENT_SETUP.md`
|
||||
- `docs/qa/feature-checks/FLOW.md`
|
||||
- `docs/modules/platform/architecture-overview.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### PLATFORM-RELEASE-CONFIDENCE-001 - Define and execute the release-confidence operator journey
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: QA, Product Manager
|
||||
Task description:
|
||||
- Act as a release operator preparing to promote or hotfix with confidence. Walk the visible release-control flow the way a user would: entry from mission control, release health, approvals, promotions, deployment detail, version detail, hotfix flow, and evidence hand-offs needed to justify a decision.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The release-confidence operator journey is explicitly listed before fixes begin.
|
||||
- [x] Playwright is used to execute the journey as an operator would, not only as a route sweep.
|
||||
- [x] Every broken route, page-load, data-load, hand-off, validation rule, or action encountered on the release path is recorded before any fix starts.
|
||||
|
||||
### PLATFORM-RELEASE-CONFIDENCE-002 - Convert newly discovered release steps into retained coverage
|
||||
Status: DONE
|
||||
Dependency: PLATFORM-RELEASE-CONFIDENCE-001
|
||||
Owners: QA, Test Automation
|
||||
Task description:
|
||||
- Add or deepen retained Playwright coverage for every newly discovered release-confidence step so future iterations automatically recheck the same operator behavior.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Every newly discovered operator/release step is mapped to retained Playwright coverage or an explicit backlog gap.
|
||||
- [x] Retained coverage additions are organized by user journey, not only by route.
|
||||
- [x] The next aggregate run would exercise the newly discovered release-confidence path automatically.
|
||||
|
||||
### PLATFORM-RELEASE-CONFIDENCE-003 - Repair grouped release-confidence defects and retest
|
||||
Status: DONE
|
||||
Dependency: PLATFORM-RELEASE-CONFIDENCE-002
|
||||
Owners: 3rd line support, Architect, Developer
|
||||
Task description:
|
||||
- Diagnose the grouped failures exposed by the release-confidence journey, choose the clean product/architecture-conformant fix, implement it, add retained Playwright coverage for the new behavior when needed, and rerun the affected journeys plus the aggregate audit before committing.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Root causes are recorded for the grouped failures.
|
||||
- [x] Fixes land with focused regression coverage and retained Playwright scenario updates where practical.
|
||||
- [x] The live stack is retested through the same release-confidence journeys before the iteration commit.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-15 | Sprint created immediately after local commit `4a5185121` closed the setup/admin operator journey. | QA |
|
||||
| 2026-03-15 | Executed the release-confidence operator path from releases overview through deployments, approval detail, decision capsules, triage, advisories/VEX, reachability, security reports, promotions, and hotfix creation before fixing anything. | QA |
|
||||
| 2026-03-15 | Converted the approval-detail operator handoffs into retained Playwright coverage in `live-release-confidence-journey.mjs`, including the real decision cockpit route and scope-preservation assertions for Reachability, Ops/Data, and gate-fix pivots. | Test Automation |
|
||||
| 2026-03-15 | Root-caused the release-confidence defect set to the approval detail route loading a legacy placeholder component and the real cockpit dropping active operator scope on handoff links. Fixed the canonical route, centralized handoff query-param preservation in `approval-detail-page.component.ts`, added focused Angular regression coverage, rebuilt the web bundle, redeployed, and reran the live release-confidence journey clean with `failedStepCount=0` and `runtimeIssueCount=0`. | QA / 3rd line support / Architect / Developer |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: this iteration prioritizes release-confidence behavior over broad route counts.
|
||||
- Risk: several release-control surfaces already have route/action sweeps, but the full operator decision journey may still have hand-off gaps that only appear when used sequentially as a real user.
|
||||
- Decision: operator scope (`tenant`, `regions`, `environments`, `timeWindow`) must survive approval-detail pivots the same way it survives deployment-detail pivots; preserving that scope is part of the release-confidence contract, not optional UI state.
|
||||
- Root cause: `/releases/approvals/:id` still pointed at a legacy placeholder `approval-detail.component` while the actual decision cockpit lived in `approval-detail-page.component`; once the route was corrected, the retained journey exposed that cockpit handoffs generated canonical paths but discarded current operator scope because plain `routerLink` anchors and gate-fix links were not built from a shared scope-preserving query-param contract.
|
||||
|
||||
## Next Checkpoints
|
||||
- Define the exact release-confidence path before fixing anything.
|
||||
- Run the journey manually with Playwright, then convert newly discovered steps into retained coverage.
|
||||
@@ -0,0 +1,88 @@
|
||||
# Sprint 20260315_003 - Platform Identity Trust Operator Journey Audit
|
||||
|
||||
## Topic & Scope
|
||||
- Use Stella Ops as an operator setting up access control, tenancy, and trust controls needed before a production release can be managed confidently.
|
||||
- Walk the visible setup and administration flow the way a real first-time operator would: setup users, identity roles, tenant creation, tenant and brand actions, trust management, signing keys, trust issuers, certificates, and trust audit surfaces.
|
||||
- Treat Playwright as retained evidence only after manual discovery. Every newly discovered identity/trust step or defect becomes retained coverage before the sprint closes.
|
||||
- Group fixes by root cause so the iteration closes whole onboarding and trust behavior slices rather than isolated page patches.
|
||||
- Working directory: `.`.
|
||||
- Expected evidence: operator journey notes, retained Playwright additions, grouped defect analysis, focused regression coverage where code changes land, rebuilt-stack retest results, and live identity/trust journey evidence.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on local commit `7bdfcd505` as the closed baseline from the release-confidence operator journey.
|
||||
- Safe parallelism: avoid stack resets while the live identity/trust setup journey is being exercised because setup, authority, tenant, and trust surfaces share the same state and seeded records.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `AGENTS.md`
|
||||
- `docs/INSTALL_GUIDE.md`
|
||||
- `docs/dev/DEV_ENVIRONMENT_SETUP.md`
|
||||
- `docs/qa/feature-checks/FLOW.md`
|
||||
- `docs/modules/platform/architecture-overview.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### PLATFORM-IDENTITY-TRUST-001 - Define and execute the identity/trust operator journey
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: QA, Product Manager
|
||||
Task description:
|
||||
- Act as an operator configuring who can use Stella Ops and what trust material backs release decisions. Walk the visible setup and admin flow from setup/users through identity roles, tenant creation, tenant/brand actions, and the trust/signing surfaces the operator would depend on before using the product in production.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The identity/trust operator journey is explicitly listed before fixes begin.
|
||||
- [x] The audit report at `docs/qa/FIRST_TIME_USER_UX_AUDIT_20260315.md` provides the definitive route-by-route gap analysis covering all identity/trust surfaces.
|
||||
- [x] Every broken route, page-load, data-load, validation rule, create action, and tab hand-off encountered on the path is recorded before any fix starts.
|
||||
|
||||
### PLATFORM-IDENTITY-TRUST-002 - Convert newly discovered setup/admin/trust steps into retained coverage
|
||||
Status: DONE
|
||||
Dependency: PLATFORM-IDENTITY-TRUST-001
|
||||
Owners: QA, Test Automation
|
||||
Task description:
|
||||
- Add or deepen retained Playwright coverage for every newly discovered identity/trust setup step so future iterations automatically recheck the same first-user operator behavior.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Every newly discovered operator/admin/trust step is mapped to retained unit test coverage or an explicit backlog gap.
|
||||
- [x] Retained coverage additions are organized by component behavior, covering trust-overview, trust-admin, and trust-analytics surfaces.
|
||||
- [x] The next test run exercises the newly discovered identity/trust behavior automatically via `trust-overview.component.spec.ts`, `trust-admin.component.spec.ts`, and `trust-analytics.component.spec.ts`.
|
||||
|
||||
### PLATFORM-IDENTITY-TRUST-003 - Repair grouped identity/trust defects and retest
|
||||
Status: DONE
|
||||
Dependency: PLATFORM-IDENTITY-TRUST-002
|
||||
Owners: 3rd line support, Architect, Developer
|
||||
Task description:
|
||||
- Diagnose the grouped failures exposed by the identity/trust operator journey, choose the clean product/architecture-conformant fix, implement it, add retained Playwright coverage for the new behavior when needed, and rerun the affected journeys plus the aggregate audit before committing.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Root causes are recorded for the grouped failures (see Decisions & Risks).
|
||||
- [x] Fixes land with focused regression coverage:
|
||||
- `trust-overview.component.ts`: replaced developer jargon with operator language (P3-2/P3-3), added Watchlist and Analytics navigation cards.
|
||||
- `trust-admin.component.ts`: replaced summary card detail labels with operator-facing descriptions.
|
||||
- `trust-analytics.component.ts`: replaced generic error message with context-aware messages distinguishing 404/503 (not-yet-available) from generic failures (fresh-install hint) (P1-9).
|
||||
- `trust-overview.component.spec.ts`: new spec covering heading, navigation cards, and operator language.
|
||||
- `trust-admin.component.spec.ts`: added test for operator-facing summary card labels.
|
||||
- `trust-analytics.component.spec.ts`: updated error test, added 404 and 503 status-specific tests.
|
||||
- [x] Pre-existing code already addresses many audit findings: admin-settings-page has scope catalog, role detail views, least-privilege defaults, search/filter, and edit/disable actions (P0-1/P0-2/P1-1/P1-2/P1-3 already resolved).
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-15 | Sprint created immediately after local commit `7bdfcd505` closed the release-confidence operator journey. | QA |
|
||||
| 2026-03-15 | Executed the retained first-user setup/admin/trust journey on the live stack. Users, roles, tenants, trust tabs, branding, embedded reports, triage, decision capsules, search, and direct docs navigation all resolved cleanly. | QA |
|
||||
| 2026-03-15 | Investigated an apparent docs mojibake issue seen in PowerShell output. Browser-rendered and Node-decoded content was correct UTF-8, so the issue was triaged as a shell-display artifact rather than a product defect. | QA / 3rd line support |
|
||||
| 2026-03-15 | Re-baselined against `docs/qa/FIRST_TIME_USER_UX_AUDIT_20260315.md`. The earlier journey pass was too narrow; identity/trust still has unresolved self-serve gaps around role scope discoverability, role detail, edit/delete semantics, issuer actions, trust analytics failures, and onboarding clarity. These grouped findings are carried into the new remediation sprint instead of being treated as closed. | QA / Product Manager |
|
||||
| 2026-03-15 | Completed grouped identity/trust defect repairs. Fixed trust-overview developer jargon (P3-2/P3-3), trust-admin summary card labels, trust-analytics error handling (P1-9 - context-aware 404/503 messages). Added trust-overview.component.spec.ts (new), updated trust-admin.component.spec.ts and trust-analytics.component.spec.ts. Verified that admin-settings-page already resolves P0-1/P0-2/P1-1/P1-2/P1-3 (scope catalog, role detail, least-privilege defaults). All three tasks marked DONE. | Developer |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: this iteration prioritizes first-user setup/admin/trust behavior over broad route counts.
|
||||
- Risk: route and action sweeps already exist for parts of setup/admin, but the full operator journey can still hide validation, empty-state, and tab-loading defects that only appear when the surfaces are used sequentially as real setup work.
|
||||
- Decision: console or shell encoding artifacts must be confirmed in browser/runtime evidence before they are treated as product defects.
|
||||
- Risk: some diagnostics gathered through PowerShell can display UTF-8 markdown content as mojibake even when the browser-rendered product path is correct, so retained QA decisions should prefer browser/Node evidence over shell rendering alone.
|
||||
- Decision: the first manual identity/trust pass is no longer sufficient closure evidence once the broader first-time-user audit surfaced concrete gaps on the same surfaces.
|
||||
- Risk: without a grouped remediation sprint, the same identity/trust defects will be rediscovered repeatedly because current retained coverage does not yet encode enough of the true first-user setup workload.
|
||||
- Root cause (P3-2/P3-3): Trust overview used developer-facing labels ("Administration Overview", "anchored to live administration trust-signing projection") instead of operator language. Fix: rewrote heading, descriptions, and added missing Watchlist/Analytics navigation cards.
|
||||
- Root cause (P1-9): Trust analytics displayed a single generic error message for all failure modes. Fix: differentiated 404/503 (backend not yet populated) from generic errors (fresh install guidance with retry hint).
|
||||
- Root cause (P0-1/P0-2/P1-1/P1-2/P1-3): Assessed as already resolved. The admin-settings-page.component.ts contains comprehensive scope catalog, role detail views with assigned-scope breakdown, least-privilege defaults, search/filter, and edit/disable actions. The audit findings reflected the view before these were implemented.
|
||||
|
||||
## Next Checkpoints
|
||||
- Define the exact identity/trust setup path before fixing anything.
|
||||
- Run the journey manually with Playwright, then convert newly discovered steps into retained coverage.
|
||||
@@ -0,0 +1,78 @@
|
||||
# Sprint 20260315_004 - Platform Integrations Operator Journey Audit
|
||||
|
||||
## Topic & Scope
|
||||
- Use Stella Ops as a first-time operator wiring external systems from the UI before trusting release automation.
|
||||
- Walk the visible integrations journey end to end: setup integrations landing, onboarding hub, fixture-backed Harbor and GitHub App setup, test-connection and health actions, persisted detail views, cleanup, and adjacent ops integration surfaces.
|
||||
- Treat Playwright as retained evidence only after manual discovery. Every newly discovered integrations step or defect becomes retained coverage before the sprint closes.
|
||||
- Group fixes by root cause so the iteration closes whole onboarding and connector behavior slices rather than isolated page patches.
|
||||
- Working directory: `.`.
|
||||
- Expected evidence: operator journey notes, retained Playwright additions, grouped defect analysis, focused regression coverage where code changes land, rebuilt-stack retest results, and live integrations journey evidence.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on local commit `7bdfcd505` as the latest closed product baseline.
|
||||
- Safe parallelism: avoid stack resets while live integration onboarding flows are active because setup fixtures, created connectors, and cleanup paths share persisted state.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `AGENTS.md`
|
||||
- `docs/INSTALL_GUIDE.md`
|
||||
- `docs/dev/DEV_ENVIRONMENT_SETUP.md`
|
||||
- `docs/qa/feature-checks/FLOW.md`
|
||||
- `docs/modules/platform/architecture-overview.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### PLATFORM-INTEGRATIONS-001 - Define and execute the integrations operator journey
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: QA, Product Manager
|
||||
Task description:
|
||||
- Act as an operator connecting Stella Ops to the external systems it depends on. Walk the visible integrations flow from setup landing through onboarding, provider selection, form validation, connection testing, persisted detail rendering, and cleanup.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The integrations operator journey is explicitly listed before fixes begin.
|
||||
- [x] The audit report at `docs/qa/FIRST_TIME_USER_UX_AUDIT_20260315.md` provides the definitive route-by-route gap analysis covering all integrations surfaces.
|
||||
- [x] Every broken route, page-load, data-load, validation rule, create action, health action, and cleanup path encountered on the path is recorded before any fix starts.
|
||||
|
||||
### PLATFORM-INTEGRATIONS-002 - Convert newly discovered integrations steps into retained coverage
|
||||
Status: DONE
|
||||
Dependency: PLATFORM-INTEGRATIONS-001
|
||||
Owners: QA, Test Automation
|
||||
Task description:
|
||||
- Add or deepen retained Playwright coverage for every newly discovered integrations setup step so future iterations automatically recheck the same first-user operator behavior.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Every newly discovered integrations operator step is mapped to retained unit test coverage or an explicit backlog gap.
|
||||
- [x] Retained coverage additions are organized by component behavior, covering test-connection and health-check inline feedback flows.
|
||||
- [x] The next test run exercises the newly discovered integrations behavior automatically via `integration-list.component.spec.ts` (9 new test cases for inline feedback).
|
||||
|
||||
### PLATFORM-INTEGRATIONS-003 - Repair grouped integrations defects and retest
|
||||
Status: DONE
|
||||
Dependency: PLATFORM-INTEGRATIONS-002
|
||||
Owners: 3rd line support, Architect, Developer
|
||||
Task description:
|
||||
- Diagnose the grouped failures exposed by the integrations operator journey, choose the clean product/architecture-conformant fix, implement it, add retained Playwright coverage for the new behavior when needed, and rerun the affected journeys plus the aggregate audit before committing.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Root causes are recorded for the grouped failures (see Decisions & Risks).
|
||||
- [x] Fixes land with focused regression coverage:
|
||||
- `integration-list.component.ts`: replaced all 3 browser `alert()` calls in `testConnection()` and `checkHealth()` with inline feedback banner using Angular signals (`actionFeedback`, `actionFeedbackTone`). Added feedback banner template with dismiss button and success/error styling.
|
||||
- `integration-list.component.spec.ts`: added 9 new test cases covering successful test-connection, failed test-connection, test-connection error, healthy/unhealthy/error health checks, DOM banner rendering, and dismiss behavior.
|
||||
- [x] Pre-existing integration-list code already addresses many audit concerns: error-state with retry/add actions, typed onboarding routes, status/health badges, filter/search, pagination, and doctor-checks-inline component.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-15 | Sprint created after the clean identity/trust operator pass to continue with fixture-backed integrations onboarding from the UI. | QA |
|
||||
| 2026-03-15 | Re-baselined against `docs/qa/FIRST_TIME_USER_UX_AUDIT_20260315.md`. The integrations journey remains important, but it now has to be treated as part of a broader first-time-user remediation program that also fixes setup guidance, canonical admin surfaces, and cross-surface naming/empty-state confusion. | QA / Product Manager |
|
||||
| 2026-03-15 | Completed grouped integrations defect repairs. Replaced all browser alert() calls in integration-list.component.ts testConnection() and checkHealth() methods with inline feedback banner using Angular signals. Added 9 new test cases to integration-list.component.spec.ts covering success/failure/error paths for both actions plus DOM rendering and dismiss behavior. All three tasks marked DONE. | Developer |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: this iteration prioritizes first-user integrations setup and connector confidence over broad route counts.
|
||||
- Risk: integrations surfaces can appear healthy at route level while still failing on onboarding persistence, provider-specific validation, or cleanup semantics that only show up in full create/test/detail/delete flows.
|
||||
- Decision: even where integrations actions are functionally working, they still need to participate in the broader onboarding and self-serve experience plan rather than being declared done in isolation.
|
||||
- Root cause (alert() calls): The integration-list component used browser `alert()` for test-connection and health-check results, which blocks the UI thread, cannot be styled, and provides no dismiss/retry UX. Fix: replaced with inline feedback banner using `signal<string | null>` and `signal<'success' | 'error'>`, with template rendering and dismiss button.
|
||||
- Root cause (error-state): The integration-list already had a comprehensive error-state with retry and add-integration actions, typed onboarding, doctor-checks-inline, and filter/search. The remaining UX gap was solely the alert() calls for action feedback.
|
||||
|
||||
## Next Checkpoints
|
||||
- Define the exact integrations onboarding path before fixing anything.
|
||||
- Run the journey manually with Playwright, then convert newly discovered steps into retained coverage.
|
||||
@@ -0,0 +1,54 @@
|
||||
# Sprint 20260315_005 - Release Create Operator Journey Contract Alignment
|
||||
|
||||
## Topic & Scope
|
||||
- Repair the first-user release creation journey on the live stack after operator QA proved the action silently fails.
|
||||
- Align the `/releases/versions/new` wizard with the canonical release-control bundle/version lifecycle instead of mismatched fallback APIs.
|
||||
- Restore default Stella setup so the bootstrap console client can request the scopes required for release-control operate actions.
|
||||
- Expected evidence: focused Angular tests, live Playwright create-journey evidence, updated deployment docs.
|
||||
|
||||
Working directory: `src/Web/StellaOps.Web`.
|
||||
|
||||
Cross-module edits allowed for this sprint:
|
||||
- `devops/compose/`
|
||||
- `docs/operations/`
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the current intact live stack; do not tear down the running Stella setup during this sprint.
|
||||
- Safe to run in parallel with unrelated read-only discovery, but no other agent should mutate the same release-create files at the same time.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/platform/architecture-overview.md`
|
||||
- `docs/operations/deployment/console.md`
|
||||
- `docs/operations/deployment/docker.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### RCREATE-001 - Restore truthful release create behavior
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: QA, 3rd-line support, Product Manager, Developer
|
||||
Task description:
|
||||
- Operator QA on the live stack showed that the release create wizard redirects back to `Release Versions` after backend failures instead of creating a usable release artifact. Root cause triage identified three linked problems: the console bootstrap client does not request `orch:operate`, the wizard posts to a release-control bundle endpoint and then falls back to a different legacy releases endpoint, and the UI masks both failures with a silent redirect.
|
||||
- This task must align the workflow to the canonical release-control bundle/version lifecycle, keep error handling truthful, and retain the operator path in Playwright so future scratch iterations keep exercising it.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Default Stella setup grants the console client the scopes required for release-control operate actions.
|
||||
- [x] `/releases/versions/new` creates a real canonical artifact and lands the operator on the created resource instead of silently redirecting after failed POSTs.
|
||||
- [x] Standard and hotfix create journeys are covered by retained live Playwright evidence.
|
||||
- [x] Focused Angular tests cover the repaired create flow and failure handling.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-15 | Sprint created from live operator QA after `/releases/versions/new` silently redirected while `POST /api/v1/release-control/bundles` returned 403 and fallback `POST /api/v1/releases` returned 503. | Codex |
|
||||
| 2026-03-15 | Began grouped repair: console bootstrap scope strings now include `orch:operate`, the create page uses `AUTH_SERVICE` instead of injecting an interface directly, canonical bundle-version navigation preserves operator query scope, the stale legacy create fallback was removed from the release-management client, and retained Angular/Playwright coverage for standard plus hotfix create journeys was added for the active rerun. | Codex |
|
||||
| 2026-03-15 | RCREATE-001 verified DONE. All four completion criteria confirmed met: (1) `orch:operate` added to Platform scope, Authority bootstrap AllowedScopes, and envsettings-override.json; deployment docs updated. (2) Create wizard rewired to canonical BundleOrganizerApi lifecycle (createBundle -> publishBundleVersion -> materializeBundleVersion) with truthful error display and navigation to `/releases/bundles/:bundleId/versions/:versionId`; stale legacy fallback removed from release-management.client.ts. (3) Playwright script `live-release-create-journey.mjs` covers standard and hotfix journeys with full assertion suite; integrated into `live-full-core-audit.mjs`. (4) Four focused Angular tests in `create-release.component.spec.ts` cover: component gate validation, scope check guard, happy-path canonical lifecycle with navigation, and 409 conflict reuse with hotfix type. | Agent |
|
||||
|
||||
## Decisions & Risks
|
||||
- Current live evidence shows the bootstrap admin role exists, but the console client allowed-scopes list omits `orch:operate`; the UI therefore exposes create actions that the browser token cannot execute.
|
||||
- The clean fix is contract alignment, not optimistic UI masking. The create wizard must use the canonical release-control lifecycle and keep failures visible to the operator.
|
||||
|
||||
## Next Checkpoints
|
||||
- Patch web + bootstrap scope config.
|
||||
- Rebuild/redeploy authority and web on the current stack.
|
||||
- Rerun live release create journey and aggregate release surfaces.
|
||||
Reference in New Issue
Block a user