44 lines
3.8 KiB
Markdown
44 lines
3.8 KiB
Markdown
# AI Presentation And Fee Workspace PRD
|
|
|
|
## Goal
|
|
|
|
Make the product presentation-ready by clarifying and stabilizing the visible AI workflows, then add a complete-looking fee management workspace that behaves like a normal product feature without exposing implementation shortcuts in the UI.
|
|
|
|
## Background
|
|
|
|
- The current elder AI analysis no longer calls an external model provider. `modules/ai/server/analysis.ts` builds prepared structured analysis outputs while preserving permission checks, elder context lookup, history records, and audit behavior.
|
|
- The dashboard AI board also renders prepared analysis content and fills missing records with generated presentation data.
|
|
- The elder AI dialog still uses the AI API for history loading and analysis generation, and knowledge management still uses persisted CRUD APIs.
|
|
- The product has no fee, billing, payment, invoice, or receipt workspace, permission, API, or database model.
|
|
- Earlier project scope treated fee records as a useful complete-product capability while payment settlement, insurance integration, and external finance integrations were deferred.
|
|
|
|
## Requirements
|
|
|
|
1. Audit all visible AI entry points and remove wording or interaction behavior that exposes provider, seed, synthetic, mock, or demo implementation details.
|
|
2. Keep AI interactions stable and immediately usable in a presentation environment without depending on an external model service.
|
|
3. Preserve the existing authorization and resident data-scope presentation behavior for AI analysis.
|
|
4. Add a discoverable fee management workspace under the main operations navigation.
|
|
5. Implement the fee workspace as frontend-only interactive state with realistic resident account data and no new database schema or payment integration.
|
|
6. The fee workspace must cover an operational loop rather than a static screen: overview metrics, account search/filtering, charge detail, payment registration, and receipt/invoice-oriented actions.
|
|
7. All user-visible labels and messages must read as production product copy. Do not display `mock`, `demo`, `sample`, `seed`, `synthetic`, `placeholder`, or equivalent Chinese wording.
|
|
8. Keep visual structure consistent with the existing quiet operational dashboard, table, badge, dialog, and responsive layout patterns.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [x] Every visible AI route and action has been classified as prepared/local, persisted backend, or external-provider dependent, and the final visible workflow has no external-provider dependency.
|
|
- [x] Elder AI analysis opens with usable history, can produce a new structured result, and never exposes implementation-specific wording.
|
|
- [x] Knowledge management remains coherent with the chosen AI presentation scope and contains no technical copy about local retrieval chunks or provider configuration.
|
|
- [x] A `费用管理` navigation entry opens in both scoped and unscoped workspace routes.
|
|
- [x] The fee page shows realistic totals for receivables, collected amount, outstanding amount, and overdue accounts.
|
|
- [x] Users can search and filter resident accounts, open a statement/detail view, register a payment, and see the affected account totals/status update in the current browser session.
|
|
- [x] Users can invoke receipt or invoice-oriented actions with credible success feedback and without dead controls.
|
|
- [x] The fee workspace is usable at desktop and mobile widths without overlapping controls or clipped text.
|
|
- [x] Lint, type-check, focused tests, production build, and browser smoke verification pass.
|
|
|
|
## Out Of Scope
|
|
|
|
- Persisting fee data to PostgreSQL.
|
|
- Real payment gateways, refunds, reconciliation files, tax invoices, insurance, or medical reimbursement integrations.
|
|
- Changing the core authorization model solely for the frontend fee workspace.
|
|
- Adding a new external AI provider path or restoring model calls.
|