## 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