This commit is contained in:
sexygoat
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -0,0 +1,57 @@
|
||||
## Context
|
||||
|
||||
The agent home page and the commission center both render a withdrawable-commission summary card from the same `GET /api/admin/shops/fund-summary` response, but they currently duplicate the markup separately.
|
||||
|
||||
That duplication has already caused drift:
|
||||
|
||||
- the home page added an inline `佣金中心` text-and-chevron chip inside the card header
|
||||
- the two cards can diverge visually even though they show the same summary concept
|
||||
- new summary fields such as `main_balance` need to be maintained in two places
|
||||
|
||||
The requested change is small in scope, but it introduces a presentation-level reuse rule that should be documented before implementation.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
- Goals:
|
||||
- Ensure the home page and commission center render the withdrawable-commission summary with the same visible structure
|
||||
- Remove the extra inline `佣金中心` chip from the home-page card
|
||||
- Centralize the repeated card markup into one shared component
|
||||
- Keep data fetching and navigation ownership in the page containers
|
||||
|
||||
- Non-Goals:
|
||||
- Redesigning commission-center record lists or search/filter areas
|
||||
- Changing the fund-summary API contract beyond the already approved username/main-balance behavior
|
||||
- Moving commission business logic out of the page containers
|
||||
|
||||
## Decisions
|
||||
|
||||
- Decision: implement one shared presentational component for the withdrawable-commission summary card.
|
||||
- Why: the two pages describe the same summary object and should not maintain separate card markup.
|
||||
|
||||
- Decision: the shared component should own display structure only; parent pages should continue to own data loading and page navigation.
|
||||
- Why: the card is reused across pages, but fetch timing and navigation context are still page-specific concerns.
|
||||
|
||||
- Decision: the home-page card must not render a separate inline `佣金中心` chip/chevron affordance inside the card header.
|
||||
- Why: the product explicitly wants that duplicate callout removed, and the surrounding page already provides navigation context.
|
||||
|
||||
- Decision: the shared summary icon should render directly in the header layout without an extra boxed wrapper surface.
|
||||
- Why: the product explicitly wants the icon treatment simplified, and keeping the icon unboxed reduces visual noise while preserving recognition.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- Risk: extracting a shared component can accidentally drop one page-specific field or visual state.
|
||||
- Mitigation: the spec requires the same core title, amount, and summary metric set on both pages.
|
||||
|
||||
- Risk: if navigation behavior is embedded into the shared component, reuse may become rigid.
|
||||
- Mitigation: keep click handling and routing in the parent pages.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Extract the repeated withdrawable-commission card markup into one shared component
|
||||
2. Replace the duplicated home-page and commission-center card markup with the shared component
|
||||
3. Remove the extra inline `佣金中心` chip from the home-page rendering
|
||||
4. Verify that both pages still show the same summary fields and formatting
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Whether the shared component should live in `src/components/` or in an `agent-system`-scoped components directory
|
||||
@@ -0,0 +1,28 @@
|
||||
# Change: Update fund-summary username filter and shared summary card display
|
||||
|
||||
## Why
|
||||
|
||||
The frontend originally sent the current agent username through the `shop_name` query parameter when calling `GET /api/admin/shops/fund-summary`, which no longer matched the backend contract. That response also includes `main_balance`, which must be shown in both the agent home page and commission center withdrawable-commission cards.
|
||||
|
||||
The two withdrawable-commission cards are also duplicated between the home page and commission center. The home page currently renders an extra inline `佣金中心` chip inside the card header, which the product no longer wants. The two pages should render the same summary card through one shared component.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Update the frontend contract for `GET /api/admin/shops/fund-summary` so self-scoped requests send the logged-in agent username under `username`, not `shop_name`
|
||||
- Keep the query value unchanged; only the parameter name changes
|
||||
- Show the backend `main_balance` field in the agent home page and commission center withdrawable-commission cards with the label `预充值余额`
|
||||
- Preserve the existing amount formatting and empty-state behavior for the summary cards
|
||||
- Remove the extra inline `佣金中心` text-and-chevron chip from the home-page withdrawable-commission card
|
||||
- Standardize the home page and commission center withdrawable-commission cards behind one shared component so the visible summary structure stays aligned
|
||||
- Remove the extra decorative icon wrapper so the summary icon is not rendered inside a separate boxed container
|
||||
|
||||
## Impact
|
||||
|
||||
- Affected specs:
|
||||
- `agent-fund-summary`
|
||||
- Affected code:
|
||||
- `src/api/commission.ts`
|
||||
- shared fund-summary card component to be introduced for agent pages
|
||||
- `src/pages/agent-system/home/index.vue`
|
||||
- `src/pages/agent-system/commission-center/index.vue`
|
||||
- `src/pages/agent-system/withdraw/index.vue`
|
||||
@@ -0,0 +1,76 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Agent Fund Summary Requests SHALL Filter By Username
|
||||
|
||||
The frontend SHALL send the current logged-in agent account identifier under the `username` query parameter when requesting self-scoped data from `GET /api/admin/shops/fund-summary`. The frontend MUST NOT send that same identifier under `shop_name`.
|
||||
|
||||
#### Scenario: Agent home page requests its own fund summary
|
||||
|
||||
- **GIVEN** the logged-in agent has `username = "agent_a"`
|
||||
- **WHEN** the home page requests `GET /api/admin/shops/fund-summary`
|
||||
- **THEN** the request includes `username=agent_a`
|
||||
- **AND** the request does not send `shop_name=agent_a`
|
||||
|
||||
#### Scenario: Commission pages request the current agent fund summary
|
||||
|
||||
- **GIVEN** the logged-in agent has `username = "agent_a"`
|
||||
- **WHEN** the commission center page or withdrawal page requests `GET /api/admin/shops/fund-summary`
|
||||
- **THEN** the request includes `username=agent_a`
|
||||
- **AND** the value is passed through unchanged from the logged-in user information
|
||||
|
||||
#### Scenario: No username is available from login state
|
||||
|
||||
- **GIVEN** the current login state does not provide a username
|
||||
- **WHEN** the frontend requests `GET /api/admin/shops/fund-summary`
|
||||
- **THEN** the frontend omits the username filter
|
||||
- **AND** the frontend does not substitute `shop_name` as a fallback filter key
|
||||
|
||||
### Requirement: Agent Fund Summary Cards SHALL Show Main Balance
|
||||
|
||||
The agent home page and commission center withdrawable-commission summary cards SHALL display the backend `main_balance` field using the label `预充值余额`. The displayed amount MUST use the same currency-formatting rules as the other fund summary amounts.
|
||||
|
||||
#### Scenario: Home page renders main balance
|
||||
|
||||
- **GIVEN** the fund summary response contains `main_balance = 200000`
|
||||
- **WHEN** the agent home page renders the withdrawable-commission card
|
||||
- **THEN** the card shows a metric labeled `预充值余额`
|
||||
- **AND** the amount is rendered using the existing summary amount formatter
|
||||
|
||||
#### Scenario: Commission center renders main balance
|
||||
|
||||
- **GIVEN** the fund summary response contains `main_balance = 200000`
|
||||
- **WHEN** the commission center page renders the withdrawable-commission card
|
||||
- **THEN** the card shows a metric labeled `预充值余额`
|
||||
- **AND** the amount is rendered using the existing summary amount formatter
|
||||
|
||||
#### Scenario: Main balance is unavailable
|
||||
|
||||
- **GIVEN** the fund summary response is missing `main_balance` or the summary has not loaded yet
|
||||
- **WHEN** either summary card renders
|
||||
- **THEN** the `预充值余额` label remains visible
|
||||
- **AND** the corresponding amount renders as `--`
|
||||
|
||||
### Requirement: Agent Fund Summary Card Presentation SHALL Stay Consistent Across Pages
|
||||
|
||||
The agent home page and commission center SHALL render the withdrawable-commission summary through one shared card presentation so the title, primary amount area, summary icon, and summary metric blocks stay visually consistent across both pages. The home-page card MUST NOT render a separate inline `佣金中心` text-and-chevron chip inside the card header. The summary icon MUST NOT be rendered inside a separate boxed wrapper surface.
|
||||
|
||||
#### Scenario: Home page and commission center share the same summary structure
|
||||
|
||||
- **GIVEN** the fund summary response has loaded on both the home page and the commission center page
|
||||
- **WHEN** the withdrawable-commission summary card renders on each page
|
||||
- **THEN** both pages show the same card title, primary amount area, summary icon treatment, and summary metric block order
|
||||
- **AND** both pages use the same summary-card presentation rather than maintaining separate duplicated markup
|
||||
|
||||
#### Scenario: Home page removes the extra commission-center chip
|
||||
|
||||
- **GIVEN** the agent home page renders the withdrawable-commission summary card
|
||||
- **WHEN** the user scans the card header area
|
||||
- **THEN** the card does not display a separate inline `佣金中心` text-and-chevron chip
|
||||
- **AND** the rest of the card content remains available
|
||||
|
||||
#### Scenario: Summary icon is not boxed
|
||||
|
||||
- **GIVEN** either summary card renders on the home page or commission center page
|
||||
- **WHEN** the user views the summary icon area
|
||||
- **THEN** the icon is displayed without an additional boxed wrapper container
|
||||
- **AND** the icon remains visually aligned with the shared card header
|
||||
@@ -0,0 +1,15 @@
|
||||
## 1. Spec
|
||||
|
||||
- [x] 1.1 Create a focused OpenSpec proposal for the fund-summary contract and card display change
|
||||
- [x] 1.2 Review and approve the proposal before implementation
|
||||
|
||||
## 2. Implementation
|
||||
|
||||
- [x] 2.1 Update `FundSummaryParams` and every `getFundSummary` caller to send `username` instead of `shop_name`
|
||||
- [x] 2.2 Display `main_balance` as `预充值余额` in the agent home withdrawable-commission card
|
||||
- [x] 2.3 Display `main_balance` as `预充值余额` in the commission center withdrawable-commission card
|
||||
- [x] 2.4 Verify request payloads and empty-state rendering for all fund-summary callers
|
||||
- [x] 2.5 Extract the home-page and commission-center withdrawable-commission summary into one shared component
|
||||
- [x] 2.6 Remove the extra inline `佣金中心` chip from the home-page summary card
|
||||
- [x] 2.7 Remove the extra boxed wrapper around the summary icon in the shared card
|
||||
- [x] 2.8 Verify that both pages render the same summary card structure and field order
|
||||
Reference in New Issue
Block a user