chore(web): prune dead ui cleanup artifacts
This commit is contained in:
master
@@ -0,0 +1,95 @@
|
||||
# Sprint 20260308_025 - FE Safe Cleanup And Generated Artifacts Prune
|
||||
|
||||
## Topic & Scope
|
||||
- Remove the approved generated and debug artifacts committed under the Web workspace so audits and review diffs stop mixing product code with disposable output.
|
||||
- Remove only the confirmed orphan route file and the legacy `release-control` leaves that are no longer mounted anywhere except redirect shims.
|
||||
- Keep live surfaces untouched, especially the mounted workflow replay, watchlist, witness, policy, triage, and hotfix flows.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Allowed coordination edits: `docs/implplan/SPRINT_20260308_025_FE_safe_cleanup_and_generated_artifacts_prune.md`, `docs/modules/ui/TASKS.md`, and `docs/modules/ui/implementation_plan.md`.
|
||||
- Expected evidence: clean git deletion set, successful Web build, successful Web test run, and execution-log updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the preservation review already completed for the current route tree and shared-component inventory.
|
||||
- Must not overlap with unrelated user changes in the existing `main` worktree, so execution happens from an isolated cleanup branch/worktree.
|
||||
- Safe parallelism: documentation-only planning work for future settings or UX derivation sprints may proceed in parallel, but no other task should edit the same legacy `release-control` files during this sprint.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `AGENTS.md`
|
||||
- `docs/modules/ui/AGENTS.md`
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `src/Web/StellaOps.Web/src/app/app.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/releases.routes.ts`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-CLN-001 - Freeze the deletion allowlist
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer (FE), Project Manager
|
||||
Task description:
|
||||
- Freeze the exact list of generated artifacts and orphan code files that are approved for deletion so the cleanup stays narrow and reviewable.
|
||||
- Reconfirm that `hotfixes-queue.component.ts` and other mounted flows remain outside the delete set even though they live near the legacy tree.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The deletion list is explicitly recorded in the sprint execution log.
|
||||
- [x] Mounted or reused components are excluded from the cleanup.
|
||||
- [x] The cleanup scope stays inside `src/Web/StellaOps.Web`.
|
||||
|
||||
### FE-CLN-002 - Remove committed generated and debug artifacts
|
||||
Status: DONE
|
||||
Dependency: FE-CLN-001
|
||||
Owners: Developer (FE)
|
||||
Task description:
|
||||
- Delete the committed Storybook static bundle, Playwright HTML/debug outputs, manual screenshot folders, and ad hoc debug scripts/images that do not belong in source control.
|
||||
- Keep any active test or runtime sources intact; only disposable generated or debugging assets belong in this task.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The approved generated/debug artifact paths are removed from source control.
|
||||
- [x] No product source file is changed as part of this deletion step.
|
||||
- [x] Git diff shows only the intended artifact removals.
|
||||
|
||||
### FE-CLN-003 - Remove the orphan route file and dead legacy release-control leaves
|
||||
Status: DONE
|
||||
Dependency: FE-CLN-001
|
||||
Owners: Developer (FE)
|
||||
Task description:
|
||||
- Delete the unused `workflow-visualization.routes.ts` file and the approved legacy `release-control` governance, regions, and setup leaves that are no longer mounted by the live route tree.
|
||||
- Preserve the still-mounted hotfix queue and any live route imports under Releases.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The orphan workflow-visualization route file is removed.
|
||||
- [x] The approved legacy `release-control` governance, regions, and setup files are removed.
|
||||
- [x] `hotfixes-queue.component.ts` remains in place and the build graph stays valid.
|
||||
|
||||
### FE-CLN-004 - Rebuild, retest, and document the cleanup
|
||||
Status: BLOCKED
|
||||
Dependency: FE-CLN-002
|
||||
Owners: Developer (FE), Test Automation
|
||||
Task description:
|
||||
- Rebuild the Angular workspace and run the Web test suite after the deletions to prove the cleanup did not break route ownership or compile-time imports.
|
||||
- Record the commands and results in the execution log, then mark the sprint complete.
|
||||
|
||||
Completion criteria:
|
||||
- [x] `npm run build` succeeds in `src/Web/StellaOps.Web`.
|
||||
- [ ] `npm run test -- --watch=false` succeeds in `src/Web/StellaOps.Web`.
|
||||
- [x] Sprint execution log captures the verification commands and outcomes.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-08 | Sprint created to prune approved generated/debug artifacts plus confirmed orphan route and legacy release-control leaves from the Web workspace. | Codex |
|
||||
| 2026-03-08 | FE-CLN-001: deletion allowlist frozen. Generated/debug removals: `storybook-static/**`, `playwright-report/index.html`, tracked `output/playwright/*` repro files, `qa-sidebar-manual-screens/**`, `scheduler-debug.png`, and `tmp-debug-*.js`. Code removals: `workflow-visualization.routes.ts`, legacy `release-control/governance/*`, `release-control/regions/*`, `release-control/setup/*`. Explicitly preserved: mounted `hotfixes-queue.component.ts` and live workflow replay components. | Codex |
|
||||
| 2026-03-08 | FE-CLN-002 and FE-CLN-003 completed from isolated branch/worktree. One stale dead-code test file, `src/Web/StellaOps.Web/src/tests/release-control/release-control-setup.component.spec.ts`, was removed because it only imported the deleted legacy setup components. | Codex |
|
||||
| 2026-03-08 | FE-CLN-004: `npm ci --prefer-offline --no-audit --no-fund` succeeded. `npm run build` succeeded with existing bundle-budget warnings only. `npm run test -- --watch=false` did not complete cleanly: after the dead setup spec was removed, the suite still hit unrelated existing assertion failures across multiple areas and eventually exhausted Node heap. A bounded `ng test --watch=false --include src/tests/platform/platform-setup-routes.spec.ts --include src/tests/release-control/release-control-structure.component.spec.ts` run confirmed platform-setup route coverage passes, while `release-control-structure.component.spec.ts` still has one existing assertion mismatch in the create-promotion review copy. | Codex |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: use an isolated cleanup branch/worktree because the user-facing `main` checkout already contains unrelated modifications.
|
||||
- Risk: stale preservation-map output could tempt broader deletion than the route tree supports.
|
||||
- Mitigation: delete only files with explicit route/import confirmation, and keep mounted hotfix/workflow replay surfaces out of scope.
|
||||
- Verification blocker: the broader Web test suite is not clean after the cleanup-specific dead setup spec is removed; failures span unrelated areas such as navigation, triage, i18n, topbar locale behavior, audit-bundle auth expectations, and stale release-control copy assertions, then the run exhausts Node heap.
|
||||
- Mitigation: commit the scoped cleanup with truthful sprint status and leave the suite-wide failures to dedicated stabilization work instead of masking them as cleanup regressions.
|
||||
|
||||
## Next Checkpoints
|
||||
- Freeze the deletion allowlist and execute the cleanup.
|
||||
- Rebuild and retest the Web workspace.
|
||||
- Fast-forward `main` to the cleanup commit after verification succeeds.
|
||||
@@ -0,0 +1,143 @@
|
||||
# Sprint 20260308_026 - FE Settings Information Architecture Rationalization
|
||||
|
||||
## Topic & Scope
|
||||
- Rationalize the current `/settings/*` tree so it becomes a truthful personal-settings surface instead of a mixed bucket of user preferences, admin consoles, setup pages, and redirect shims.
|
||||
- Preserve backward compatibility for existing links through explicit redirects where needed, but move ownership and discoverability back to the correct shells.
|
||||
- Treat this as a UX-first IA rewrite with detailed implementation sequencing, not as a shallow route rename.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Allowed coordination edits: `docs/modules/ui/TASKS.md`, `docs/modules/ui/implementation_plan.md`, `src/Web/StellaOps.Web/src/app/features/settings/**`, `src/Web/StellaOps.Web/src/app/core/navigation/navigation.config.ts`, relevant canonical owner routes under `src/Web/StellaOps.Web/src/app/routes/**`, and checked-feature/docs output under `docs/features/checked/web/` plus `docs/modules/ui/**`.
|
||||
- Expected evidence: route inventory, IA contract, Angular route/nav tests, UX verification notes, and execution-log updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the current route inventory and the review that classified settings leaves into personal, admin/setup, and alias buckets.
|
||||
- Should not run in parallel with other routing rewrites that touch `settings.routes.ts`, user-menu navigation, or canonical Setup/Admin ownership paths.
|
||||
- Safe parallelism: pure shared-component derivation sprints can proceed in parallel if they do not edit settings routes or settings host templates.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `AGENTS.md`
|
||||
- `docs/modules/ui/AGENTS.md`
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `src/Web/StellaOps.Web/AGENTS.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/settings/settings.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/core/navigation/navigation.config.ts`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-SETIA-001 - Audit and classify every settings route
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, Developer (FE)
|
||||
Task description:
|
||||
- Produce the source-of-truth route inventory for every child of `/settings`, classifying each leaf as one of: personal preference, admin or tenant configuration, canonical-owner alias, or dead wrapper.
|
||||
- Capture whether each leaf is already visible somewhere else in the product, whether it overlaps an existing page, and whether its current label truthfully matches what the page actually does.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Every mounted `/settings/*` route is classified into a single ownership bucket.
|
||||
- [ ] Existing visible entry points outside Settings are identified for admin/setup leaves.
|
||||
- [ ] Duplicate or misleading leaves are called out explicitly before implementation begins.
|
||||
|
||||
### FE-SETIA-002 - Freeze the target IA and backward-compatibility contract
|
||||
Status: TODO
|
||||
Dependency: FE-SETIA-001
|
||||
Owners: Product Manager, UX
|
||||
Task description:
|
||||
- Define the target contract for Settings so the shell only owns true personal preferences, while admin, tenant, policy, trust, and operations configuration live under their canonical Setup, Ops, or Console Admin owners.
|
||||
- Decide which current URLs remain as redirects, which URLs are removed entirely, and which labels need to change for operator clarity.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] A final ownership decision exists for each current settings leaf.
|
||||
- [ ] Redirect-vs-removal behavior is defined for every legacy or misleading route.
|
||||
- [ ] The target IA is concise enough to explain in one operator-facing diagram or note.
|
||||
|
||||
### FE-SETIA-003 - Build the personal-settings shell and navigation model
|
||||
Status: TODO
|
||||
Dependency: FE-SETIA-002
|
||||
Owners: UX, Developer (FE)
|
||||
Task description:
|
||||
- Redesign the Settings shell around personal preferences only, with explicit sections such as Appearance, Language, Assistant, and Navigation/Layout.
|
||||
- Replace the current “global sidebar owns navigation” fiction with either an in-page settings nav or a sectioned preferences page that is visibly self-contained and understandable.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] The Settings shell has a truthful navigation model for personal preferences.
|
||||
- [ ] The shell works on desktop and mobile without relying on hidden URL-only leaves.
|
||||
- [ ] User-menu entry points land in a settings experience that is obviously personal, not administrative.
|
||||
|
||||
### FE-SETIA-004 - Merge overlapping personal preference leaves
|
||||
Status: TODO
|
||||
Dependency: FE-SETIA-003
|
||||
Owners: Developer (FE), UX
|
||||
Task description:
|
||||
- Consolidate `language` and any other overlapping preference leaves into the primary User Preferences experience so personal settings are not split across near-duplicate pages.
|
||||
- Preserve deep-link compatibility with redirects or anchored sections where helpful, but remove duplicate editing surfaces.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Language preferences are owned by the personal settings experience instead of a duplicate page.
|
||||
- [ ] Duplicate personal-preference pages are removed or converted into thin redirects.
|
||||
- [ ] Preference-saving behavior remains intact after the merge.
|
||||
|
||||
### FE-SETIA-005 - Rehome admin, tenant, and operations configuration leaves
|
||||
Status: TODO
|
||||
Dependency: FE-SETIA-002
|
||||
Owners: Developer (FE), Product Manager
|
||||
Task description:
|
||||
- Move or redirect `integrations`, `admin`, `branding`, `notifications`, `usage`, `system`, `security-data`, `identity-providers`, `policy`, `offline`, and related leaves to their correct canonical owners.
|
||||
- Ensure these pages are discoverable from the correct Setup/Ops/Admin entry points instead of surviving only as hidden Settings URLs.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Admin/setup leaves no longer present themselves as user settings.
|
||||
- [ ] Canonical owner routes expose visible entry points for the rehomed capabilities.
|
||||
- [ ] Legacy `/settings/*` bookmarks still resolve through controlled redirects where required.
|
||||
|
||||
### FE-SETIA-006 - Remove or collapse wrapper and alias-only settings pages
|
||||
Status: TODO
|
||||
Dependency: FE-SETIA-005
|
||||
Owners: Developer (FE)
|
||||
Task description:
|
||||
- Delete or collapse any settings pages that only exist as wrapper launchpads into other shells and do not provide independent value.
|
||||
- Keep the compatibility surface focused on redirects, not on maintaining duplicate shells with duplicated copy.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Alias-only settings pages are reduced to redirects or removed.
|
||||
- [ ] No standalone wrapper remains if its only action is to link elsewhere.
|
||||
- [ ] Route ownership becomes obvious from the code tree.
|
||||
|
||||
### FE-SETIA-007 - Add focused route, nav, and UX regression coverage
|
||||
Status: TODO
|
||||
Dependency: FE-SETIA-004
|
||||
Owners: Test Automation, Developer (FE)
|
||||
Task description:
|
||||
- Add regression coverage for the new Settings IA, including user-menu entry, redirected legacy URLs, and canonical owner entry points for rehomed admin/setup pages.
|
||||
- Include tests that prove hidden pages are now either visible from the right place or intentionally redirected.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Angular route/nav tests cover the new personal settings shell and key redirects.
|
||||
- [ ] Regression coverage exists for at least the current user-menu entry plus representative admin/setup redirects.
|
||||
- [ ] Known IA edge cases are documented in the sprint log or feature note.
|
||||
|
||||
### FE-SETIA-008 - Sync docs and ship the IA decision
|
||||
Status: TODO
|
||||
Dependency: FE-SETIA-007
|
||||
Owners: Documentation author, Project Manager
|
||||
Task description:
|
||||
- Record the final Settings IA contract in the UI docs, update the UI task board and implementation plan, and add a checked-feature note once the implementation ships.
|
||||
- Ensure future dead-code or preservation reviews have a truthful owner map for Settings.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] UI docs reflect the final Settings ownership model.
|
||||
- [ ] UI task/plan docs reference the shipped IA.
|
||||
- [ ] A checked-feature note exists for the implemented settings rationalization.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-08 | Sprint created to rationalize Settings into a truthful personal-preferences surface and rehome admin/setup leaves to their canonical owners. | Codex |
|
||||
|
||||
## Decisions & Risks
|
||||
- Current risk: the existing Settings shell mixes user preferences with admin/setup pages, making most leaves either URL-only or misleadingly named.
|
||||
- UX principle: Settings must answer “what can I personalize for myself?” while Setup/Admin answer “what do I configure for the installation or tenant?”
|
||||
- Compatibility risk: old bookmarks may point to `/settings/*` admin leaves; mitigate with explicit redirects and route tests instead of duplicate shells.
|
||||
|
||||
## Next Checkpoints
|
||||
- Complete the route classification matrix.
|
||||
- Freeze the target IA and redirect contract.
|
||||
- Implement personal-settings shell changes only after the ownership map is agreed.
|
||||
@@ -0,0 +1,86 @@
|
||||
# Sprint 20260308_027 - FE Page Header To Context Header Derivation
|
||||
|
||||
## Topic & Scope
|
||||
- Replace the unused generic `PageHeaderComponent` with a stronger canonical header pattern derived from the already-mounted `ContextHeaderComponent`.
|
||||
- Improve operator UX by standardizing title, eyebrow, chips, return action, contextual note, and header actions across admin and setup surfaces.
|
||||
- Keep this sprint focused on header semantics, layout, and adoption, not on broader page redesign.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Allowed coordination edits: `docs/modules/ui/TASKS.md`, `docs/modules/ui/implementation_plan.md`, `src/Web/StellaOps.Web/src/app/shared/ui/**`, target mounted pages that adopt the header, and checked-feature/docs output under `docs/features/checked/web/` plus `docs/modules/ui/**`.
|
||||
- Expected evidence: shared-header contract, focused component tests, adopted target pages, and docs updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the current shared-UI inventory and the existence of mounted `ContextHeaderComponent` usage in Watchlist, Reachability, Workflow Replay, and Policy shells.
|
||||
- Safe parallelism: may run in parallel with settings IA work if it avoids editing `settings.routes.ts`; coordinate carefully if Settings adopts the derived header.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `src/Web/StellaOps.Web/src/app/shared/ui/page-header/page-header.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/shared/ui/context-header/context-header.component.ts`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-PHD-001 - Freeze the canonical header contract
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: UX, Developer (FE)
|
||||
Task description:
|
||||
- Compare `PageHeaderComponent` against the mounted `ContextHeaderComponent` and define the single canonical header contract the product should keep.
|
||||
- Document which capabilities remain mandatory: contextual eyebrow, chips, back action, action slot strategy, supportive note, and responsive stacking behavior.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] A single canonical header API is defined.
|
||||
- [ ] Unused or redundant `PageHeaderComponent` behavior is either absorbed or rejected explicitly.
|
||||
- [ ] Header semantics are described in UX terms, not only implementation terms.
|
||||
|
||||
### FE-PHD-002 - Derive the reusable header primitive
|
||||
Status: TODO
|
||||
Dependency: FE-PHD-001
|
||||
Owners: Developer (FE)
|
||||
Task description:
|
||||
- Extend or refine the canonical header primitive so it can serve the pages that previously would have used the generic page header without regressing the richer contextual flows.
|
||||
- Keep the API small and expressive; avoid two near-identical shared header components.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] The canonical header primitive supports the required title, metadata, and action variants.
|
||||
- [ ] `PageHeaderComponent` is either removed or reduced to a compatibility wrapper with a clear migration path.
|
||||
- [ ] Header behavior remains responsive and accessible.
|
||||
|
||||
### FE-PHD-003 - Adopt the derived header on target pages
|
||||
Status: TODO
|
||||
Dependency: FE-PHD-002
|
||||
Owners: Developer (FE), UX
|
||||
Task description:
|
||||
- Adopt the derived header on carefully chosen mounted surfaces that currently rely on ad hoc title/subtitle/action markup, prioritizing pages that need contextual clarity.
|
||||
- Use adoption to prove the pattern works for both dense operator surfaces and simpler settings/admin pages.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] At least one simple settings/admin page and one richer operational page adopt the derived header pattern.
|
||||
- [ ] Repeated header markup is removed from adopted surfaces.
|
||||
- [ ] The adopted pages gain clearer context and action placement.
|
||||
|
||||
### FE-PHD-004 - Verify, document, and retire the orphan path
|
||||
Status: TODO
|
||||
Dependency: FE-PHD-003
|
||||
Owners: Test Automation, Documentation author
|
||||
Task description:
|
||||
- Add focused tests for the canonical header behavior and record the derivation decision in UI docs so future reviews treat the old generic header as intentionally superseded.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Component or host tests cover the canonical header behavior.
|
||||
- [ ] UI docs explain the header derivation and adoption targets.
|
||||
- [ ] The old orphan path is no longer ambiguous in the shared inventory.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-08 | Sprint created to derive the unused generic page header into the mounted context-header pattern and adopt one canonical header primitive. | Codex |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision target: one canonical header primitive, not parallel “simple” and “contextual” header abstractions.
|
||||
- Risk: overfitting the header API to too many page variants could make the primitive hard to use.
|
||||
- Mitigation: validate the API on a small adoption set before broad rollout.
|
||||
|
||||
## Next Checkpoints
|
||||
- Freeze the canonical header contract.
|
||||
- Prototype the derived shared header.
|
||||
- Adopt it on a bounded set of mounted pages.
|
||||
@@ -0,0 +1,85 @@
|
||||
# Sprint 20260308_028 - FE Metric Card Dashboard Derivation
|
||||
|
||||
## Topic & Scope
|
||||
- Derive the unused `MetricCardComponent` into a truthful canonical KPI card pattern for mounted ops, admin, quota, and system dashboards.
|
||||
- Improve UX by standardizing deltas, directional semantics, health coloring, and supporting context instead of leaving each dashboard to invent its own card shape.
|
||||
- Keep scope to KPI card behavior and adoption, not entire dashboard rewrites.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Allowed coordination edits: `docs/modules/ui/TASKS.md`, `docs/modules/ui/implementation_plan.md`, shared UI card primitives, selected dashboard hosts, and checked-feature/docs output under `docs/features/checked/web/` plus `docs/modules/ui/**`.
|
||||
- Expected evidence: canonical KPI card contract, bounded adoption set, focused tests, and docs updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the mounted overview surfaces already present across Operations, Administration, Usage, System, and related overview pages.
|
||||
- Safe parallelism: may run alongside settings IA work if adoptions do not edit the same settings-owned templates; coordinate if Usage/System pages are part of both efforts.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `src/Web/StellaOps.Web/src/app/shared/ui/metric-card/metric-card.component.ts`
|
||||
- Mounted dashboard or overview pages chosen for adoption
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-MCD-001 - Freeze KPI semantics and visual rules
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: UX, Product Manager
|
||||
Task description:
|
||||
- Define what a canonical StellaOps KPI card must communicate: label, value, unit, trend/delta, severity or health state, supporting subtitle, and empty/loading/error behaviors.
|
||||
- Decide when positive deltas are good vs bad, so the shared component does not encode misleading green/red assumptions.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] KPI card semantic fields are explicitly defined.
|
||||
- [ ] Delta direction rules are documented for operational contexts where “higher” can be either good or bad.
|
||||
- [ ] The visual contract includes empty/loading/error states where needed.
|
||||
|
||||
### FE-MCD-002 - Derive the shared KPI card primitive
|
||||
Status: TODO
|
||||
Dependency: FE-MCD-001
|
||||
Owners: Developer (FE)
|
||||
Task description:
|
||||
- Rework the current `MetricCardComponent` into the canonical dashboard card pattern with the agreed semantics, layout, and accessibility behavior.
|
||||
- Keep the API reusable across quota, health, system, and admin overview surfaces without requiring ad hoc wrappers.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] The shared KPI card supports the agreed semantic model.
|
||||
- [ ] Directional styling does not assume all positive movement is good.
|
||||
- [ ] The component is accessible and responsive in dense dashboard grids.
|
||||
|
||||
### FE-MCD-003 - Adopt the derived KPI card on representative dashboards
|
||||
Status: TODO
|
||||
Dependency: FE-MCD-002
|
||||
Owners: Developer (FE), UX
|
||||
Task description:
|
||||
- Adopt the new KPI card on a representative mix of mounted dashboard pages so the shared primitive proves itself in real product surfaces.
|
||||
- Prioritize pages with repeated bespoke KPI tiles or weak visual consistency.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] A bounded set of mounted dashboard pages use the shared KPI card.
|
||||
- [ ] Repeated bespoke KPI tile markup is reduced on adopted surfaces.
|
||||
- [ ] The adopted dashboards present clearer health/trend information.
|
||||
|
||||
### FE-MCD-004 - Verify and document the derivation
|
||||
Status: TODO
|
||||
Dependency: FE-MCD-003
|
||||
Owners: Test Automation, Documentation author
|
||||
Task description:
|
||||
- Add focused component or host tests for semantic delta handling and document the shared KPI-card contract in the UI docs.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Tests cover the critical semantic cases for delta and state rendering.
|
||||
- [ ] Docs record the adopted KPI-card contract and target surfaces.
|
||||
- [ ] Future audits can classify the old unused component as intentionally derived, not forgotten.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-08 | Sprint created to derive the orphan metric-card into a canonical KPI card pattern for mounted dashboards and overview surfaces. | Codex |
|
||||
|
||||
## Decisions & Risks
|
||||
- Key risk: dashboard metrics have different “good/bad” semantics, so a naive green-for-up, red-for-down treatment would be wrong.
|
||||
- Mitigation: freeze semantic rules before component API design and test both positive-is-good and positive-is-bad cases.
|
||||
|
||||
## Next Checkpoints
|
||||
- Freeze KPI semantics and state rules.
|
||||
- Build the canonical shared KPI card.
|
||||
- Adopt it on a bounded dashboard set.
|
||||
@@ -0,0 +1,85 @@
|
||||
# Sprint 20260308_029 - FE Timeline List Audit Timeline Derivation
|
||||
|
||||
## Topic & Scope
|
||||
- Derive the unused `TimelineListComponent` into a canonical event-stream pattern for mounted audit, evidence, release investigation, and triage chronology surfaces.
|
||||
- Improve UX by standardizing chronology rendering, severity markers, timestamp treatment, and expandable contextual payloads.
|
||||
- Keep scope to the timeline primitive plus bounded adoptions, not a full redesign of every evidence or run-detail screen.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Allowed coordination edits: `docs/modules/ui/TASKS.md`, `docs/modules/ui/implementation_plan.md`, shared timeline primitives, selected mounted timeline hosts, and checked-feature/docs output under `docs/features/checked/web/` plus `docs/modules/ui/**`.
|
||||
- Expected evidence: canonical timeline contract, bounded adoption set, regression coverage, and docs updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the mounted evidence, release, and triage chronology surfaces already present in the product.
|
||||
- Safe parallelism: may run with settings or header/card derivation work if it avoids editing the same host templates.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `src/Web/StellaOps.Web/src/app/shared/ui/timeline-list/timeline-list.component.ts`
|
||||
- Relevant mounted timeline/audit hosts chosen for adoption
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-TLD-001 - Freeze the canonical event model
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: UX, Product Manager
|
||||
Task description:
|
||||
- Define the canonical event model for StellaOps timelines, including timestamp precision, actor/source metadata, severity or event kind, optional evidence links, and empty/loading states.
|
||||
- Decide where relative time, absolute time, and grouping should appear so audit and ops surfaces remain truthful and scannable.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] A canonical event model exists for mounted timeline surfaces.
|
||||
- [ ] Rules for relative vs absolute time display are documented.
|
||||
- [ ] Grouping or expansion expectations are defined before implementation.
|
||||
|
||||
### FE-TLD-002 - Derive the shared timeline primitive
|
||||
Status: TODO
|
||||
Dependency: FE-TLD-001
|
||||
Owners: Developer (FE)
|
||||
Task description:
|
||||
- Rework `TimelineListComponent` so it can serve real audit/evidence use cases: richer markers, deterministic timestamp formatting, optional metadata slots, and expandable event detail.
|
||||
- Avoid keeping a toy timeline component that cannot carry actual operator evidence.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] The shared timeline primitive supports the agreed event model.
|
||||
- [ ] Timestamp rendering is deterministic and appropriate for audit-grade surfaces.
|
||||
- [ ] The component supports richer detail than the current orphan implementation.
|
||||
|
||||
### FE-TLD-003 - Adopt the derived timeline on mounted chronology surfaces
|
||||
Status: TODO
|
||||
Dependency: FE-TLD-002
|
||||
Owners: Developer (FE), UX
|
||||
Task description:
|
||||
- Adopt the derived timeline on a small set of mounted chronology surfaces where it improves consistency without flattening domain-specific meaning.
|
||||
- Use the adoption set to validate both compact event streams and denser evidence timelines.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] A bounded set of mounted chronology surfaces adopt the shared timeline.
|
||||
- [ ] Timeline UX improves on scanability and event meaning.
|
||||
- [ ] Domain-specific context is preserved, not lost to over-generalization.
|
||||
|
||||
### FE-TLD-004 - Verify and document the derivation
|
||||
Status: TODO
|
||||
Dependency: FE-TLD-003
|
||||
Owners: Test Automation, Documentation author
|
||||
Task description:
|
||||
- Add focused regression coverage for timeline formatting and document the canonical timeline contract and adoption choices.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Tests cover core timeline rendering and timestamp behavior.
|
||||
- [ ] Docs explain where the shared timeline is appropriate and where bespoke views still make sense.
|
||||
- [ ] The old orphan classification becomes intentional and documented.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-08 | Sprint created to derive the unused timeline-list into a canonical event-stream pattern for mounted audit and evidence chronologies. | Codex |
|
||||
|
||||
## Decisions & Risks
|
||||
- Risk: oversimplifying audit/evidence timelines could erase domain meaning or precision.
|
||||
- Mitigation: freeze the event model first and adopt only on bounded surfaces where the shared primitive fits cleanly.
|
||||
|
||||
## Next Checkpoints
|
||||
- Freeze the event model and time-display rules.
|
||||
- Build the richer shared timeline primitive.
|
||||
- Adopt it on a bounded set of mounted chronology surfaces.
|
||||
@@ -0,0 +1,86 @@
|
||||
# Sprint 20260308_030 - FE Split Pane And List Detail Shell Consolidation
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate the unused `SplitPaneComponent` into the mounted `ListDetailShellComponent` so the product has one truthful master-detail layout primitive instead of two overlapping abstractions.
|
||||
- Improve UX by defining a single responsive list-detail behavior for selection, secondary detail presentation, and mobile collapse behavior.
|
||||
- Keep scope to master-detail layout primitives and their bounded adoptions.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Allowed coordination edits: `docs/modules/ui/TASKS.md`, `docs/modules/ui/implementation_plan.md`, shared shell primitives, selected mounted list-detail hosts, and checked-feature/docs output under `docs/features/checked/web/` plus `docs/modules/ui/**`.
|
||||
- Expected evidence: consolidated shell contract, updated shared primitive, bounded host adoption, and regression coverage.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the mounted `ListDetailShellComponent` usage already present in Watchlist and related contextual surfaces.
|
||||
- Safe parallelism: may run with other derivation sprints if it avoids editing the same host templates; coordinate closely with any watchlist or triage shell changes.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `src/Web/StellaOps.Web/src/app/shared/ui/split-pane/split-pane.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/shared/ui/list-detail-shell/list-detail-shell.component.ts`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-SPL-001 - Freeze the single master-detail contract
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: UX, Developer (FE)
|
||||
Task description:
|
||||
- Compare the unused `SplitPaneComponent` against the mounted `ListDetailShellComponent` and freeze the single master-detail contract the UI should keep.
|
||||
- Decide which behaviors, if any, should migrate: collapsible secondary rail, width control, preserved selection context, and mobile stacking behavior.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] One canonical master-detail layout contract is defined.
|
||||
- [ ] Useful `SplitPaneComponent` behavior is explicitly accepted or rejected.
|
||||
- [ ] The contract describes both desktop and mobile behavior.
|
||||
|
||||
### FE-SPL-002 - Derive the canonical list-detail shell
|
||||
Status: TODO
|
||||
Dependency: FE-SPL-001
|
||||
Owners: Developer (FE)
|
||||
Task description:
|
||||
- Extend `ListDetailShellComponent` with the approved behavior from `SplitPaneComponent` if it materially improves operator UX.
|
||||
- Avoid porting gimmicks that add complexity without improving mounted surfaces.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] `ListDetailShellComponent` supports the agreed master-detail behavior.
|
||||
- [ ] The API remains smaller and clearer than maintaining two primitives.
|
||||
- [ ] Accessibility and responsive behavior are preserved.
|
||||
|
||||
### FE-SPL-003 - Adopt the consolidated shell on bounded mounted surfaces
|
||||
Status: TODO
|
||||
Dependency: FE-SPL-002
|
||||
Owners: Developer (FE), UX
|
||||
Task description:
|
||||
- Adopt the consolidated shell on a bounded set of mounted list-detail surfaces, validating both steady-state browsing and detail-open workflows.
|
||||
- Prefer surfaces where the detail panel and selection behavior are central to task completion.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Bounded mounted list-detail surfaces use the consolidated shell.
|
||||
- [ ] Detail-open and mobile behaviors are tested on real host pages.
|
||||
- [ ] `SplitPaneComponent` becomes removable or clearly deprecated.
|
||||
|
||||
### FE-SPL-004 - Verify and document the consolidation
|
||||
Status: TODO
|
||||
Dependency: FE-SPL-003
|
||||
Owners: Test Automation, Documentation author
|
||||
Task description:
|
||||
- Add focused tests for the consolidated shell behavior and document the single master-detail contract in the UI docs.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Regression coverage exists for the consolidated shell.
|
||||
- [ ] Docs explain the one-shell rule for future UI work.
|
||||
- [ ] The old unused split-pane path is no longer ambiguous.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-08 | Sprint created to consolidate the unused split-pane primitive into the mounted list-detail shell and establish one canonical master-detail layout. | Codex |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision target: one master-detail primitive with a narrow, justified API.
|
||||
- Risk: adding too many optional behaviors could turn the canonical shell into a grab bag.
|
||||
- Mitigation: migrate only behaviors that improve mounted operator flows.
|
||||
|
||||
## Next Checkpoints
|
||||
- Freeze the single master-detail contract.
|
||||
- Implement the justified shell improvements.
|
||||
- Adopt and verify on bounded mounted surfaces.
|
||||
@@ -0,0 +1,87 @@
|
||||
# Sprint 20260308_031 - FE Witness Viewer Evidence Derivation
|
||||
|
||||
## Topic & Scope
|
||||
- Derive the orphan `WitnessViewerComponent` into reusable evidence and witness sub-surfaces inside the mounted Reachability and Evidence experiences instead of reviving a standalone full-page viewer.
|
||||
- Improve UX by surfacing verification summary, signatures, attestations, raw evidence actions, and supporting metadata where operators already investigate proofs.
|
||||
- Keep scope to witness/evidence presentation and derivation, not backend API redesign.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Allowed coordination edits: `docs/modules/ui/TASKS.md`, `docs/modules/ui/implementation_plan.md`, witness/evidence shared UI under `src/Web/StellaOps.Web/src/app/shared/ui/**`, mounted Reachability/Evidence hosts, and checked-feature/docs output under `docs/features/checked/web/` plus `docs/modules/ui/**`.
|
||||
- Expected evidence: derivation contract, extracted reusable sections, bounded host adoption, focused tests, and docs updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the mounted reachability witness and evidence-detail flows already present in the route tree.
|
||||
- Should coordinate with any concurrent reachability or evidence route work because the adoption targets are live operator pages.
|
||||
- Safe parallelism: header/card/timeline derivation sprints may proceed separately if they do not edit the same witness/evidence hosts.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `src/Web/StellaOps.Web/src/app/shared/ui/witness-viewer/witness-viewer.component.ts`
|
||||
- Mounted reachability witness and evidence-detail hosts chosen for adoption
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-WVD-001 - Freeze the witness/evidence derivation contract
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, UX
|
||||
Task description:
|
||||
- Audit which parts of `WitnessViewerComponent` still add value: verification summary, signature inspection, attestation details, raw payload access, and download/copy actions.
|
||||
- Decide which mounted surfaces should own those capabilities, and which full-page viewer behavior should be rejected as redundant.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Valuable witness/evidence capabilities are explicitly listed.
|
||||
- [ ] Each capability is assigned to a mounted owner surface.
|
||||
- [ ] Standalone full-page viewer behavior is either justified or rejected explicitly.
|
||||
|
||||
### FE-WVD-002 - Extract reusable witness/evidence sections
|
||||
Status: TODO
|
||||
Dependency: FE-WVD-001
|
||||
Owners: Developer (FE)
|
||||
Task description:
|
||||
- Extract the useful witness/evidence sections from the orphan component into reusable building blocks that can be embedded in mounted Reachability and Evidence views.
|
||||
- Keep the extracted units focused and composable instead of recreating the orphan full-page layout under a different name.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Reusable witness/evidence sections exist for the approved capabilities.
|
||||
- [ ] The extracted units fit mounted pages without forcing a standalone-shell layout.
|
||||
- [ ] The old full-page witness viewer is no longer the only place those behaviors exist.
|
||||
|
||||
### FE-WVD-003 - Adopt the extracted sections on mounted witness and evidence surfaces
|
||||
Status: TODO
|
||||
Dependency: FE-WVD-002
|
||||
Owners: Developer (FE), UX
|
||||
Task description:
|
||||
- Integrate the extracted sections into the mounted Reachability witness and Evidence proof/detail experiences so operators can verify and inspect proofs in context.
|
||||
- Use adoption to improve context continuity rather than adding one more isolated viewer entry point.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Mounted witness/evidence flows gain the approved proof-inspection capabilities.
|
||||
- [ ] Context is preserved across reachability/evidence workflows.
|
||||
- [ ] No duplicate standalone viewer surface is introduced.
|
||||
|
||||
### FE-WVD-004 - Verify and document the derivation
|
||||
Status: TODO
|
||||
Dependency: FE-WVD-003
|
||||
Owners: Test Automation, Documentation author
|
||||
Task description:
|
||||
- Add focused tests for the derived witness/evidence sections and document where proof verification details now live in the product.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Focused tests cover the derived witness/evidence sections.
|
||||
- [ ] Docs explain the new owner surfaces for witness/proof inspection.
|
||||
- [ ] The orphan witness-viewer path is intentionally retired or reduced.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-08 | Sprint created to derive the orphan witness-viewer into reusable proof-inspection sections for mounted Reachability and Evidence surfaces. | Codex |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision target: embed proof inspection where operators already work, not as a separate full-page product island.
|
||||
- Risk: over-extracting the orphan viewer could bring layout or HTTP assumptions that do not fit the mounted flows.
|
||||
- Mitigation: freeze capabilities first, then extract only the reusable sections that serve mounted host pages.
|
||||
|
||||
## Next Checkpoints
|
||||
- Freeze the witness/evidence capability map.
|
||||
- Extract reusable proof-inspection sections.
|
||||
- Adopt them into mounted Reachability and Evidence surfaces.
|
||||
@@ -4,6 +4,7 @@
|
||||
- [DONE] `docs/implplan/SPRINT_20260308_014_FE_orphan_copy_inline_truncate_adoption.md` - CopyToClipboard, InlineCode, TruncatePipe adoption on console-admin, offline-kit, and triage replay-command surfaces.
|
||||
- [DONE] `docs/implplan/SPRINT_20260308_015_FE_orphan_filter_bar_unification.md` - Initial FilterBarComponent adoption batch; audit-log-table and trust-audit-log were later rolled back in sprint `024` to restore lost semantics.
|
||||
- [DONE] `docs-archived/implplan/SPRINT_20260308_024_FE_orphan_revival_regression_remediation.md` - Fixed reviewed orphan-revival regressions: build blockers cleared, canonical evidence-thread navigation restored, audit/trust filter capabilities restored, and fabricated finding evidence removed from mounted hosts.
|
||||
- [DOING] `docs/implplan/SPRINT_20260308_025_FE_safe_cleanup_and_generated_artifacts_prune.md` - Approved UI cleanup to prune committed generated/debug artifacts plus confirmed orphan route and legacy release-control leaves.
|
||||
|
||||
## Queued Sprint Links
|
||||
- `docs/modules/ui/orphan-revival-batch/README.md` - review index for the orphan shared-component and disconnected-route revival batch.
|
||||
@@ -18,6 +19,12 @@
|
||||
- `docs/implplan/SPRINT_20260308_021_FE_unreachable_evidence_thread_and_persona_workspaces_routes.md`
|
||||
- `docs/implplan/SPRINT_20260308_022_FE_unreachable_release_investigation_routes.md`
|
||||
- `docs/implplan/SPRINT_20260308_023_FE_unreachable_registry_admin_route.md`
|
||||
- `docs/implplan/SPRINT_20260308_026_FE_settings_information_architecture_rationalization.md`
|
||||
- `docs/implplan/SPRINT_20260308_027_FE_page_header_context_header_derivation.md`
|
||||
- `docs/implplan/SPRINT_20260308_028_FE_metric_card_dashboard_card_derivation.md`
|
||||
- `docs/implplan/SPRINT_20260308_029_FE_timeline_list_audit_timeline_derivation.md`
|
||||
- `docs/implplan/SPRINT_20260308_030_FE_split_pane_list_detail_shell_consolidation.md`
|
||||
- `docs/implplan/SPRINT_20260308_031_FE_witness_viewer_evidence_derivation.md`
|
||||
|
||||
## Delivery Tasks
|
||||
- [DONE] 041-T1 Root IA/nav rewrite (Mission Control + Ops + Setup)
|
||||
|
||||
@@ -6,12 +6,13 @@ Provide a living plan for UI deliverables, dependencies, and evidence.
|
||||
## Active work
|
||||
- Track current sprints under `docs/implplan/SPRINT_*.md` for this module.
|
||||
- Update this file when new scoped work is approved.
|
||||
- No active UI remediation sprint is open right now.
|
||||
- Sprint `025` is active for safe cleanup of approved dead leaves and committed generated/debug artifacts in the Web workspace.
|
||||
|
||||
## Near-term deliverables
|
||||
- No active UI deliverables are currently staged in `docs/implplan`.
|
||||
- The next queued batch is `docs/modules/ui/orphan-revival-batch/README.md`, which stages independent review-ready sprints for orphan shared-component adoption and disconnected-route integration.
|
||||
- The queued orphan batch currently spans `SPRINT_20260308_013` through `SPRINT_20260308_023` and is intentionally not marked active until product review approves staffing.
|
||||
- Newly queued follow-on planning sprints cover Settings information architecture rationalization plus UX derivation tracks for the orphan `PageHeaderComponent`, `MetricCardComponent`, `TimelineListComponent`, `SplitPaneComponent`, and `WitnessViewerComponent` (`SPRINT_20260308_026` through `SPRINT_20260308_031`).
|
||||
- Sprint `014` (CopyToClipboard, InlineCode, TruncatePipe adoption) is DONE. See `docs/features/checked/web/orphan-copy-inline-truncate-adoption.md`.
|
||||
- Sprint `015` (FilterBarComponent adoption) shipped, then was partially rolled back on audit-family pages to restore lost filter semantics. See `docs/features/checked/web/filter-bar-unification.md` and `docs/features/checked/web/orphan-revival-regression-remediation-ui.md`.
|
||||
- Sprint `020` (FindingListComponent consolidation) shipped, then was rolled back on mounted findings and release-security hosts because the shared contract required fabricated data. See `docs/features/checked/web/orphan-finding-list-consolidation.md` and `docs/features/checked/web/orphan-revival-regression-remediation-ui.md`.
|
||||
|
||||
Reference in New Issue
Block a user