Console (Web UI) Guide

The Stella Ops Console is the web UI for CTO, DevOps, security manager, developer, auditor, and administrator workflows inside the customer/operator organization. It is built for fast triage and auditability: decisions link back to concrete evidence, and workflows continue to work in air-gapped deployments via Offline Kit snapshots.

This is a usage guide (what the Console does and how to operate it). For UI implementation architecture, see docs/modules/ui/architecture.md.

Scope

• Console workspaces and what each is for
• Common operator workflows (triage, evidence review, exports)
• Offline/air-gap posture and what to expect in the UI
• Links to deeper module documentation
• Role-specific paths for CTO, DevOps, security managers, and developers

Out of scope: API shapes, schema details, and UI component implementation.

Primary User Paths

The Console should keep four role paths explicit:

The developer path must not be hidden inside admin or broad operator pages. Developers need a scoped view of owned services, candidate image digests, current deployed digests, scan/policy status, allowed environments, and promotion/update requests. The current Console route is /developer/services; it aggregates live Release Control deployments, releases, and security findings, filters by service/environment ABAC when those claims are issued, and only enables direct updates or approval requests that the backend will authorize.

See docs/product/user-roles.md for the canonical role boundaries. See docs/modules/ui/persona-workspace-gap-analysis.md for the current page-level gap analysis from the local console crawl.

Core Concepts

• Tenant context: most views are tenant-scoped; switching tenants changes what evidence you see and what actions you can take.
• Evidence-linked decisions: verdicts (ship/block/needs-exception) should link to the SBOM facts, advisory/VEX observations, reachability proofs, and policy explanations that justify them.
• Effective VEX: the platform computes an effective status using issuer trust and policy rules, without rewriting upstream VEX (see docs/VEX_CONSENSUS_GUIDE.md).
• Snapshots and staleness: offline sites operate on snapshots; the Console should surface snapshot identity and freshness rather than hide it.

Console Appearance

• The console palette is anchored on Stella night for structure and sunny yellow for emphasis.
• Light mode uses warm neutral content surfaces so tables, cards, drawers, and settings panels feel closer to the Stella brand instead of cold blue-gray chrome.
• Light-mode primary actions use a deeper Stella-night blue with warm text; sunny yellow remains the focus, accent, and brand-emphasis color rather than the default fill for every major button.
• Dark mode uses night surfaces with sunny yellow primary actions and warm off-white text for contrast.
• The palette follows role-based color guidance: surface tokens create page depth, primary tokens identify the most important action, and text/button contrast remains checked against WCAG 2.2 AA expectations.
• Operators change their local console theme from Settings > User Preferences > Appearance or Setup > System > Appearance. Both surfaces use the same shared theme control and persist through the local stellaops.theme preference.
• The same Appearance control includes Status and action emphasis. High visibility is the default for warning labels and status tags on evidence-gating pages; it keeps blended semantic fills rather than raw alert blocks. Row actions remain visibly clickable text controls with hover and focus affordance, not status-style badges. Operators can choose the quieter balanced setting for dense review screens.
• Tenant administrators can tune the refreshed palette from Theme & Branding, including surfaces, text, borders, sidebar/navigation, status chips, severity chips, focus/selection states, primary buttons, and inline actions. Components should use the shared --color-* design-system tokens so settings changes affect badges, filters, quick links, navigation, and primary actions consistently.
• The Theme & Branding preview should show concrete product scenarios, not a generic sample page: navigation, source freshness warnings, status chips, finding severity, selected rows, form focus/error states, actions, and night mode must all be visible enough for an admin to judge a palette before saving.
• Tenant-wide logos and brand overrides remain under Setup > Tenant & Branding; the theme control changes only the current user’s browser experience.

Workspaces (Navigation)

The Console is organized into workspaces. Names vary slightly by build, but the intent is stable:

• Dashboard: fleet status, feed/VEX age, queue depth, and policy posture.
• Developer services: owned microservices, candidate OCI digests, scan/policy results, and allowed environment updates.
• Scans / SBOM: scan history and scan detail; SBOM viewing and export.
• Findings / Triage: the vulnerability triage surface (case view + evidence rail).
• Advisories & VEX: provider status, conflicts, provenance, and issuer trust.
• Policies: policy packs, previews, promotion workflow, and waiver/exception flows.
• Runs / Scheduler: background jobs, re-evaluation, and reachability/delta work.
• Downloads / Offline: Offline Kit and signed artifact distribution and mirroring.
• Admin: tenants, roles/scopes, clients, quotas, and operational settings.

Developer Image Update Workflow

1. Open Developer services or the service-specific release page.
2. Select one owned microservice and review its current deployed digest by environment.
3. Select a candidate image digest produced by CI/registry integration.
4. Confirm scan, SBOM, reachability, and policy status.
5. If the target environment permits developer self-service, submit the image update for that service/environment.
6. If the target environment requires approval, create a promotion/update request for DevOps, security, or policy approvers.
7. Review the resulting evidence and audit trail from the service page or release request detail.

Developer tokens must be constrained by tenant plus service/environment ABAC. A developer update action should never require ui.admin, broad orch:operate, release:bypass, policy:approve, or unrestricted release:publish.

Current implementation note: /developer/services can queue a real Release Orchestrator deployment only when the session includes explicit release:write, owned service claims, allowed environment claims, maxEnvironmentType, directUpdateAllowed=true, a non-blocking gate, and an immutable candidate digest. If the live release projection does not yet expose the newest image, the developer can paste the new sha256: digest into the candidate field; mutable tags still do not enable the action. If direct update is not allowed or a gate requires review, the page can create a developer update approval request through POST /api/v1/release-orchestrator/approvals/developer-requests when the service, environment, and digest ABAC checks pass. Release Orchestrator enforces the same rules server-side for both direct deployment creation and approval-request creation.

When no visible release matches the contributor token, My Services shows the effective service, repository, image-namespace, environment, ceiling, and direct-update claims that were actually used. It never substitutes tenant-wide data. The recovery state tells the contributor to have an access administrator align those identifiers and offers one real Scan an image action when the session can scan.

Developer block explanations distinguish missing ownership claims, missing immutable digests, stale scan/feed freshness, incomplete SBOM evidence, policy gates, and findings risk. The developer links into findings and SBOM inventory keep the same service context as a read-only filter, so remediation context is visible without exposing security-manager controls.

Developer-originated requests remain visible to operators without becoming operator power for the developer. /releases/approvals labels developer service updates separately from DevOps promotions, security exceptions, and policy gates. /releases/deployments exposes service, initiating developer, source type, and digest filters, and shows a read-only developer-originated request panel sourced from the live approvals API; approval actions remain outside the developer view unless the user also holds operator/approver scopes.

Tenant administrators assign this access from Setup > Identity & Access > Users by choosing role/service-release-contributor or the legacy role/release-developer bundle, then filling service IDs, repository IDs, image namespaces, environment IDs, environment ceiling, and direct-update policy. The form warns before combining service-release contribution with broad admin, operator, bypass, publisher, or policy-approver roles.

Common Operator Workflows

Review Assurance Packs

Open Proof > Compliance (/assurance) to review optional NIS2, DORA, CRA, and future framework packs. This route is the portfolio overview; each current framework opens as a distinct cockpit route rather than an in-page tab:

1. Review the NIS2, DORA, and CRA readiness cards, then check the priority queue for blocked or unavailable packs.
2. Use the pack matrix to compare enablement, owner, mode, export readiness, reporting readiness, and the primary review workspace.
3. Open /assurance/nis2, /assurance/dora, or /assurance/cra from its readiness card or the Compliance sidebar children. Each cockpit shows framework-specific evidence workspaces, scoped readiness actions, evidence lanes, setup gaps, and pack details.
4. Open a pack workspace only after confirming whether the blocker is Authority setup, ExportCenter readiness, or reporting handoff readiness. Use All frameworks in the cockpit header to return to the portfolio overview.
5. Treat disabled packs as optional tenant setup choices, not failed compliance.

The Assurance page must keep customer/operator settings separate from sealed deployment posture, signing secrets, and legal certification claims. It may show live readiness and operator-owned configuration counts, but it must not label Stella Ops as NIS2, DORA, or CRA compliant.

Triage a Finding

1. Open Findings. The default view is Active findings, not baseline review, so the page should immediately show scoped findings or an actionable empty state.
2. If the selected tenant/region/environment has no rows, use the empty-state actions: scan an image, open the SBOM graph, review advisory sources, or view all tenant findings when rows exist outside the selected scope.
3. Switch to Review only when comparing a scan against a baseline or investigating material changes between scans.
4. Open a finding to review:
   • Verdict + “why” summary
   • Effective VEX status and issuer provenance
   • Reachability/impact signals (when available)
   • Policy explanation trace and the gate that produced the verdict
5. Record a triage action (assign/comment/ack/mute/exception request) with justification.
6. Export an evidence bundle when review, escalation, or offline verification is required.

See docs/VULNERABILITY_EXPLORER_GUIDE.md for the conceptual model and determinism requirements.

AI Remediation and Pull Requests

The AI Remediate panel provides automated remediation guidance and can create pull requests to fix vulnerabilities.

Opening the AI Remediate Panel:

1. From a finding detail view, click AI Remediate.
2. The panel generates remediation recommendations (upgrade, patch, mitigate, workaround).
3. Review recommendations sorted by priority and effort level.

Creating a Remediation PR:

When SCM connections are configured:

1. Select an SCM connection from the dropdown.
2. Click Open PR to create a pull request with the recommended fix.
3. Monitor progress with the loading indicator.
4. On success, view the PR link, branch name, and CI status.

PR Status Display:

CI Status Indicators:

When SCM Not Configured:

If no SCM connections are available, the panel shows a link to the Integrations Hub to configure GitHub, GitLab, or other SCM providers.

Error Handling:

Remediation PR Settings:

Configure remediation PR behavior in Settings > AI > Remediation Pull Requests:

Organization-Level Settings:

Some settings are controlled at the organization level:

• Enabled: If disabled at org level, all PR creation is blocked
• Require Approval: When enabled, PRs require approval before merge
• Default Labels: Labels added automatically to all remediation PRs
• Default Reviewers: Reviewers assigned automatically when enabled

Storage Key: stellaops.remediation-pr.preferences

Review VEX Conflicts and Issuer Trust

• Use Advisories & VEX to see which providers contributed statements, whether signatures verified, and where conflicts exist.
• The Console should not silently hide conflicts; it should show what disagrees and why, and how policy resolved it.
• Security Posture and Ops > Operations > Feeds & Airgap now both expose a direct Configure Sources handoff so stale or disabled advisory feeds can be corrected from the posture and operations owner pages without drilling through secondary panels first.
• The Configure Sources panel now includes persisted source settings for GHSA, Cisco, Microsoft, Oracle, Adobe, and Chromium. Stored secrets are shown only as retained state; leaving a secret field blank preserves the retained server-side value unless the operator explicitly clears it.

See docs/VEX_CONSENSUS_GUIDE.md for the underlying concepts.

Bootstrap Integrations in the Recommended Order

• Use Setup > Integrations as the first-stop onboarding page for new tenants.
• The Suggested Setup Order card now shows the recommended sequence, a short “why this matters” explanation for each connector class, and a completion badge driven by the live connector counts.
• The intended order is: Registries -> Source Control -> CI/CD -> Advisory & VEX Sources -> Secrets.
• Treat the badges as an onboarding checklist: Done means Stella already has at least one connector in that category; Not started means the category still blocks part of the release-evidence flow.
• For Advisory & VEX Sources, use the handoff into Configure Sources to enter GHSA, Cisco, and Microsoft credentials or to override Oracle, Adobe, and Chromium public endpoints for mirrored deployments.

Contextual Helper and Educational Empty States

• The Stella Helper is no longer route-only on key onboarding surfaces. Dashboard, Approvals, Integrations, topology pages, Deployments, Supply-Chain Data, Unknowns, and Policy Audit now push live context such as no-environments, approval-pending, critical-open, agents-none, no-sbom-components, no-audit-events, empty-table, and empty-list so the helper can explain what the operator should do next.
• On mobile widths below 992px, the helper starts collapsed even on an unseen route so it cannot cover the page’s primary work. The user can still open it explicitly from the Stella control.
• Treat helper context wiring as a page-owned responsibility: each page should publish a scoped set of current states, and clear that scope automatically on destroy so stale tips do not leak across routes.
• Empty states should teach, not just report absence. On queue, release, security, topology, and audit screens, prefer: what data is missing, why Stella needs it, and the next action to take.
• The current baseline examples are the Releases catalog, the Audit & Compliance overview, and the shared topology inventory page. All three now explain what should eventually appear in the table, why the page matters, and where the operator should go next when it is empty.
• Route pages should also render the shared About this page panel directly under the title area. The panel opens by default on a first visit, explains key concepts and common actions, and persists the user’s collapsed state through StellaPreferencesService.

Sidebar Context

• The sidebar now reuses the canonical navigation metadata as operator-facing context, instead of relying on unlabeled section names alone.
• Section headers should include a short description of what belongs in that area of the product. Keep these explanations one sentence and action-oriented.
• Top-level navigation items may render a short helper line under the label when the sidebar is expanded. Use the canonical item tooltip text first; only add local fallback copy when the route is not present in navigation.config.ts.
• Sidebar children should mirror same-page tabs or same-shell child pages. Cross-owner destinations belong as sibling workspaces in the group that owns the workflow, not as nested shortcuts under an unrelated Settings bucket.
• Sidebar children for parent menu items stay collapsed unless the current route is the parent route, the current route is one of the child pages, or the operator opens that parent submenu.
• Badge chips should explain what they count. Current examples: Deployments combines failed runs and pending approvals, Releases counts blocked gates, and Vulnerabilities counts critical findings still awaiting triage.
• On first-visit paths, highlight only the next recommended onboarding stop and auto-open its nav group. The current guided order is: Diagnostics -> Integrations -> Scan Image -> Dashboard.

Command Palette Help

• The Ctrl+K palette now supports inline help commands without leaving the current flow.
• Use help: <term> to search the current glossary terms. Example: help: sbom explains the term and routes to the most relevant page for deeper context.
• Use guide: first setup to launch the setup wizard from the palette, with the setup workflow steps surfaced inline first.
• Use guide: scan image to show the scan workflow as ordered inline steps: open the scan form, review supply-chain data, then triage the findings.
• Plain searches can surface Help & Guides results alongside indexed docs/API/Doctor results, so glossary and workflow guidance stays visible even when the user does not type the explicit command prefix.

Glossary Tooltips

• Stella now keeps a central domain glossary in the plain-language service and uses it for both command-palette help results and inline tooltip annotations.
• Tooltip definitions are written for developers, not security specialists. Each definition should answer two questions quickly: what the term means, and why the operator should care.
• Auto-detection wraps only the first occurrence of a term inside a given block of copy to avoid turning whole paragraphs into link soup.
• Shared onboarding surfaces now annotate glossary terms by default: ContextHeaderComponent, both app-empty-state implementations, and the pages that already opted into stellaopsGlossaryTooltip.
• Legacy routed pages that still render raw header.page-header or div.page-header blocks are covered centrally from AppShellComponent, so older screens inherit glossary help without per-page imports.
• High-value terms now covered include: SBOM, VEX, CVE, CVSS, EPSS, KEV, Reachability, DSSE, Attestation, Policy Gate, Policy Pack, Evidence Bundle, Promotion, Exception, Digest, and Provenance.

Status Chip Guidance

• The topbar status chips are part of onboarding, not just diagnostics chrome. Tooltips should explain what each signal means in plain language and what the operator should do when it goes red or stale.
• Current warning states include actionable guidance, such as missing policy baselines or offline advisory feeds, so the tooltip can point the operator at the next setup or recovery step.
• Keep the copy practical: what changed, why it matters to release decisions, and which page or workflow resolves it.

Export and Verify Evidence Bundles

• Exports are intended to be portable and verifiable (audits, incident response, air-gap review).
• Expect deterministic ordering, UTC timestamps, and hash manifests.

See docs/OFFLINE_KIT.md for packaging and offline verification workflows.

Export Evidence Cards (v1.1)

Evidence Cards are single-file exports containing SBOM excerpt, DSSE envelope, and optional Rekor receipt for offline verification.

To export an Evidence Card:

1. Open an evidence pack from Findings or Runs workspace.
2. Click the Export dropdown in the pack viewer header.
3. Select Evidence Card for full export or Evidence Card (Compact) for a smaller file without full SBOM.
4. The browser downloads a .evidence-card.json file.

Evidence Card contents:

• cardId: Unique card identifier
• version: Schema version (e.g., “1.0.0”)
• packId: Source evidence pack ID
• subject: Finding/CVE/component metadata
• envelope: DSSE signature envelope (when signed)
• sbomExcerpt: Relevant SBOM component data (full export only)
• rekorReceipt: Sigstore Rekor transparency log receipt (when available)
• contentDigest: SHA-256 digest for verification

Content types:

• Full: application/vnd.stellaops.evidence-card+json
• Compact: application/vnd.stellaops.evidence-card-compact+json

See docs/api/evidence-decision-api.openapi.yaml for the complete schema.

Grey Queue and Unknowns Triage

The Grey Queue surfaces observations with uncertain status requiring operator attention or additional evidence. This is distinct from the standard triage queue.

Grey Queue Panel Features:

• Band indicator: Shows priority band (HOT, WARM, COLD, GREY) with color coding
• Observation state badge: Displays current state (PendingDeterminization, Disputed, GuardedPass)
• Fingerprint section: Shows deterministic reanalysis fingerprint for reproducibility
• Triggers list: Sorted by receivedAt (descending), shows what events caused reanalysis
• Conflicts section: Highlights conflicting evidence with severity coloring
• Next actions: Badges showing suggested resolution paths (await_vex, run_reachability, manual_review)
• Triage actions: Buttons for resolve, escalate, and defer actions

Observation States:

Accessing the Grey Queue:

1. Navigate to Findings > Grey Queue tab.
2. Filter by observation state, priority band, or trigger type.
3. Click an item to open the Grey Queue Panel with full details.
4. Review conflicts and suggested next actions.
5. Take a triage action (resolve, escalate, or defer) with justification.

Conflict Display:

Conflicts show the source disagreements:

• Status mismatch: Different providers report conflicting vulnerability status
• VEX/reachability contradiction: VEX says not_affected but reachability proves otherwise
• Trust tie: Equal trust scores with opposite conclusions

See docs/VEX_CONSENSUS_GUIDE.md for conflict detection semantics.

Risk Line Display

The Risk Line is an always-visible summary bar in finding detail views showing reachability evidence at a glance.

Risk Line Sections:

Reachability Score Levels:

Runtime Status Badges:

Evidence Link:

When evidence is anchored to a Rekor transparency log:

• Click the Log #NNNNNN link to view the entry in Rekor
• A [OK] badge indicates the log entry has been verified
• The timestamp shows when evidence was recorded

Graceful Fallbacks:

• If reachability data is unavailable, the score displays “–” with “(no data)” hint
• If runtime status is unknown, the UI clearly shows “Unknown” rather than implying “Not Observed”
• Missing Rekor entries display “No Rekor entry” message

Trace Export

Export reachability call graphs for offline analysis or integration with other tools.

Export Formats:

To Export a Trace:

1. Open a finding with reachability evidence.
2. In the reachability panel, click Export.
3. Select the desired format.
4. The file downloads with a deterministic filename: {artifactDigest}_{findingId}.{format}

Export Contents:

• Nodes: Functions/methods in the call path with file:line locations
• Edges: Call relationships with type (direct/indirect/virtual/async)
• Runtime confirmation: Which edges were observed in runtime traces
• Metadata: Analysis timestamp, analyzer version, confidence scores

Determinism Guarantee:

Exports use deterministic ordering:

• Nodes sorted by canonical ID
• Edges sorted by (from, to) tuple
• Timestamps in ISO-8601 UTC format

AI Code Guard Badge

The AI Code Guard Badge displays scan results for AI-generated code in scan and PR views.

Badge States:

Count Badge:

When findings exist, a count badge shows the total with severity-based coloring:

• Critical count > 0: Red background
• High count > 0: Red background (lighter)
• Medium count > 0: Amber background
• Low count > 0: Gray background

Accessibility:

The badge includes proper ARIA attributes:

• role="status" for screen reader announcements
• aria-label with verdict and count (e.g., “AI Code Guard: Block, 3 findings”)

Usage:

The badge appears in:

• Scan summary views
• PR/MR check status
• Finding detail headers
• Policy gate results

Binary Diff Explain Panel

The Binary Diff Explain Panel shows binary artifact comparison evidence in the evidence panel tabs.

Panel Sections:

Section Status:

Segment Types:

Symbol Change Types:

Confidence Levels:

Export:

Click Export to download the full binary diff analysis as JSON for offline review or integration with other tools.

Show More:

When sections or symbols exceed 5 items, a “Show More” button expands the full list. Click “Show Less” to collapse.

Runtime-Confirmed Call Graph

The reachability call graph highlights runtime-confirmed paths:

Legend:

User Settings:

Runtime overlays and trace export can be toggled in Settings > Display Preferences:

• Show Runtime Overlays: Highlight runtime-confirmed edges (default: on)
• Enable Trace Export: Show export actions in reachability panel (default: on)

Display Preferences

The Display Preferences panel allows users to customize triage and finding views. Settings are persisted to browser localStorage and apply immediately.

Access: Navigate to Settings > Display > Triage Display Preferences

Available Settings:

Graph Settings:

Storage Key: stellaops.display.preferences

Reset: Click Reset to Defaults to restore all settings to their default values.

Offline / Air-Gap Expectations

• The Console must operate against Offline Kit snapshots (no external lookups required).
• The UI should surface snapshot identity and staleness budgets (feeds, VEX, policy versions).
• Upload/import workflows for Offline Kit bundles should be auditable (who imported what, when).

Setup Wizard

The Setup Wizard provides a guided interface for initial platform configuration and reconfiguration. It communicates with the Platform backend via /api/v1/setup/* endpoints.

Wizard Features

• Session-based workflow: Sessions track progress across steps, enabling resume after interruption.
• Step validation: Each step includes Doctor checks that validate configuration before proceeding.
• Dry-run mode: Preview configuration changes before applying them.
• Error handling: Problem+JSON errors are mapped to user-friendly messages with suggested fixes.
• Data freshness: Stale data banners show when cached information may be outdated.
• Retry support: Failed operations can be retried with backoff and attempt tracking.

Wizard Steps

The wizard guides operators through these configuration areas:

Using the Wizard

1. Access the Setup Wizard from Admin > Configuration Wizard or during first-run.
2. Complete required steps (Database, Cache) before optional integrations.
3. Use Test Connection to validate credentials before applying.
4. Review validation checks (Doctor diagnostics) for each step.
5. Use dry-run mode to preview changes before committing.
6. After completion, restart services to apply the configuration.

Determinization Configuration Pane

The Determinization Config Pane allows policy admins to view and edit grey queue settings.

Accessing the Configuration Pane:

1. Navigate to Admin > Policy Configuration.
2. Select the Determinization tab.
3. Non-admins see read-only view; admins see an Edit button.

Configuration Sections:

Editing Configuration:

1. Click Edit to enter edit mode.
2. Modify trigger toggles, conflict actions, or thresholds.
3. Server-side validation errors appear inline.
4. Provide a change reason (required for audit trail).
5. Click Save to apply changes.
6. View change history in the Audit Log section.

Environment Threshold Presets:

Notes:

• Configuration changes require policy-admin scope.
• Changes are audited with timestamp, user, and reason.
• In offline deployments, config is read from Offline Kit bundles.

Reconfiguration

To modify existing configuration:

• Use stella setup --reconfigure (CLI) or Admin > Configuration Wizard (UI).
• Individual steps can be reconfigured without re-running the entire wizard.

See docs/setup/setup-wizard-ux.md for detailed UX specifications and CLI parity.

Security and Access

• Authentication is typically OIDC/OAuth2 via Authority; scopes/roles govern write actions.
• Treat tokens as sensitive; avoid copying secrets into notes/tickets.
• For CSP, scopes, and DPoP posture, see docs/security/console-security.md.

Observability and Accessibility

• UI telemetry and metrics guidance: docs/modules/telemetry/guides/ui-telemetry.md.
• Accessibility baseline and keyboard model: docs/modules/ui/accessibility.md.

Deploy and Install References

• Deployment configuration and health checks: docs/operations/deployment/console.md.
• Container install recipes: docs/operations/console-docker-install.md.

Detailed References

Operator-facing deep dives (Console):

• docs/modules/ui/operations/airgap-console.md
• docs/modules/ui/operations/admin-tenants.md
• docs/modules/ui/operations/forensics.md
• docs/modules/ui/operations/observability-guide.md

UX and interaction contracts:

• docs/modules/ui/guides/ux/TRIAGE_UX_GUIDE.md

Related Docs

• docs/VEX_CONSENSUS_GUIDE.md
• docs/VULNERABILITY_EXPLORER_GUIDE.md
• docs/OFFLINE_KIT.md
• docs/modules/cli/cli-vs-ui-parity.md
• docs/technical/architecture/console-admin-rbac.md
• docs/technical/architecture/console-branding.md