fix: bug

openspec/changes/update-agent-index-layout-and-theme-tokens/design.md

@@ -0,0 +1,51 @@
+## Context
+
+The project already contains a theme file at `src/static/styles/theme.scss`, but the actual app styling is inconsistent:
+
+- `theme.scss` defines `--brand-*`, text, background, border, and utility classes
+- `src/uni.scss` and `uno.config.ts` still reference `--theme-*` variables
+The requested change is a cross-cutting design-system alignment focused on the project-wide theme contract.
+
+## Goals / Non-Goals
+
+- Goals:
+  - Define a single source of truth for the core project palette
+  - Use exactly three core brand colors for layout-level styling:
+    - Primary: `#2F7D32`
+    - Secondary: `#1F2937`
+    - Tertiary: `#F4FBF5`
+  - Ensure shared consumers such as UnoCSS utilities and uView theme variables resolve from the same theme source
+
+- Non-Goals:
+  - Full repo-wide page cleanup in one implementation pass
+  - Redefining semantic success, warning, and error states for every page
+  - Removing light/dark theme support
+
+## Decisions
+
+- Decision: `src/static/styles/theme.scss` will remain the only file that contains literal core brand values.
+  - Why: this file already acts as the closest thing to a design-token source, and centralizing values here avoids duplicating palette values across styling systems.
+
+- Decision: `src/uni.scss` and `uno.config.ts` will consume compatibility aliases exported from the same theme source rather than define their own brand colors.
+  - Why: the current `--theme-*` and `--brand-*` split is inconsistent and invites drift. Compatibility aliases let existing consumers keep working while the project converges on one source.
+
+- Decision: layout-level accents in touched agent-facing pages and shared components will be limited to the approved primary, secondary, tertiary, and neutral tokens.
+  - Why: the project had mixed blue, green, orange, red, purple, and cyan across normal layout decoration, which weakens hierarchy and visual cohesion.
+
+- Decision: semantic success, warning, and error colors may remain for exceptional states only.
+  - Why: status badges, destructive actions, and warnings still need semantic distinction, but these colors should not become the default decorative palette for dashboards and cards.
+
+## Risks / Trade-offs
+
+- Risk: changing the core palette may alter the look of existing shared utilities.
+  - Mitigation: keep the implementation scoped to shared tokens plus touched pages, and validate affected agent pages after the token update.
+
+## Migration Plan
+
+1. Define the approved brand palette and compatibility aliases in `src/static/styles/theme.scss`
+2. Update `src/uni.scss` and `uno.config.ts` to reference the shared aliases
+3. Verify touched shared utilities and agent pages for palette consistency
+
+## Open Questions
+
+- Which additional agent-facing pages should be migrated to the shared token set in the next cleanup pass

openspec/changes/update-agent-index-layout-and-theme-tokens/proposal.md

@@ -0,0 +1,25 @@
+# Change: Update shared theme tokens
+
+## Why
+
+The project currently has inconsistent theme entry points: `src/static/styles/theme.scss` defines `--brand-*` variables, while `src/uni.scss` and `uno.config.ts` still reference `--theme-*` variables. This prevents a clean single-source design system and makes brand updates drift across pages.
+
+## What Changes
+
+- Establish a single theme source for the project color system in `src/static/styles/theme.scss`
+- Re-define the core project palette as:
+  - Primary: `#2F7D32`
+  - Secondary: `#1F2937`
+  - Tertiary: `#F4FBF5`
+- Require page and component layout accents to consume shared theme tokens instead of page-local hard-coded hex values
+- Align UnoCSS and uView theme mappings with the shared theme source
+
+## Impact
+
+- Affected specs:
+  - `design-theme-tokens`
+- Affected code:
+  - `src/static/styles/theme.scss`
+  - `src/uni.scss`
+  - `uno.config.ts`
+  - shared agent-facing components that currently rely on page-local brand hex colors

openspec/changes/update-agent-index-layout-and-theme-tokens/specs/design-theme-tokens/spec.md

@@ -0,0 +1,41 @@
+## ADDED Requirements
+
+### Requirement: Project Brand Tokens SHALL Be Defined In One Theme Source
+
+The project SHALL define its core layout brand palette in `src/static/styles/theme.scss` as the single source of truth. The core brand palette MUST be:
+
+- Primary: `#2F7D32`
+- Secondary: `#1F2937`
+- Tertiary: `#F4FBF5`
+
+Compatibility aliases and helper tokens MAY exist, but they MUST be declared from the same theme source and MUST NOT introduce unrelated page-local brand colors.
+
+#### Scenario: Shared brand emphasis resolves from one source
+
+- **GIVEN** a page or component uses shared brand emphasis such as `text-brand`, `bg-brand`, `border-brand`, UnoCSS theme colors, or uView primary-theme values
+- **WHEN** the app renders those styles
+- **THEN** they resolve from the palette defined in `src/static/styles/theme.scss`
+- **AND** they do not define a separate hard-coded primary hex outside that theme source
+
+#### Scenario: A core brand value changes
+
+- **GIVEN** a developer updates one of the core brand values in `src/static/styles/theme.scss`
+- **WHEN** the project rebuilds
+- **THEN** shared brand utilities and theme consumers reflect the updated value without needing page-level color edits
+
+### Requirement: Layout-Level Brand Usage SHALL Consume Shared Tokens
+
+Agent-facing pages and shared components SHALL use shared theme tokens for layout-level accents instead of page-local hard-coded brand hex values. Semantic success, warning, and error colors MAY remain for exceptional states, destructive actions, or state badges, but SHALL NOT be used as the default decorative palette for normal dashboard and card layouts.
+
+#### Scenario: Agent-facing layout colors are reviewed
+
+- **GIVEN** an agent-facing page or shared component is reviewed for colors
+- **WHEN** it renders navigation states, buttons, highlight cards, decorative surfaces, and metric blocks
+- **THEN** those layout accents use the primary, secondary, tertiary, or neutral theme tokens
+- **AND** normal layout decoration does not depend on page-local blue, orange, purple, cyan, or red accent values
+
+#### Scenario: Shared theme consumers remain aligned
+
+- **GIVEN** `src/uni.scss` and `uno.config.ts` provide theme mappings for components and utilities
+- **WHEN** they expose primary colors to downstream styles
+- **THEN** they reference the shared theme source rather than maintaining independent brand values

openspec/changes/update-agent-index-layout-and-theme-tokens/tasks.md

@@ -0,0 +1,12 @@
+## 1. Spec
+
+- [x] 1.1 Review the existing theme/token entry points
+- [x] 1.2 Draft proposal, design notes, and spec deltas for centralized theme tokens
+- [x] 1.3 Review and approve the proposal before implementation
+
+## 2. Implementation
+
+- [x] 2.1 Update `src/static/styles/theme.scss` to define the approved primary, secondary, and tertiary palette and expose compatibility aliases from the same file
+- [x] 2.2 Align `src/uni.scss` and `uno.config.ts` with the shared theme source
+- [x] 2.3 Replace touched page-local brand hex values with shared tokens where this change already updated agent-facing views
+- [x] 2.4 Verify that touched layouts and components use the shared theme source and preserve mobile readability