spec.md 2.3 KB

ADDED Requirements

Requirement: Table naming for plan domain

All new plan-domain relational tables introduced for this program SHALL use the pl_ name prefix.

Scenario: Migration uses pl prefix

  • WHEN a developer adds a new plan persistence table
  • THEN its physical name SHALL start with pl_

Requirement: SQL change discipline

The system evolution SHALL minimize alterations to existing CRM and weighbridge historical schemas; prefer additive columns, new link tables, and backward-compatible views.

Scenario: Additive change preferred

  • WHEN a new field is needed on an existing CRM contract table
  • THEN the change SHALL be documented as additive with default for old rows unless an exception is approved in migration risk log

Requirement: Reuse CRM identity administration

User management and role management for plan-related access SHALL integrate with the existing CRM user/role administration (single source of truth or delegated sync documented in deployment guide).

Scenario: CRM role maps to plan permission

  • WHEN a CRM role is granted a plan module permission code
  • THEN holders of that role SHALL obtain corresponding authorization in the plan service after integration milestone completion

Requirement: Menu dimensions for web and mobile

The permission model SHALL distinguish web menus from mobile menus for the unified platform.

Scenario: Mobile menu entry without web

  • WHEN an administrator assigns only mobile menu visibility for a plan screen
  • THEN the web menu tree SHALL not show that entry and the mobile manifest SHALL include it

Requirement: Documentation location

Project documentation for this build SHALL be filed under docs/系统文档/ in the repository (paths relative to repo root).

Scenario: Stage summary discoverable

  • WHEN a phase completes
  • THEN a stage summary markdown file SHALL exist under docs/系统文档/stages/ with naming including date and milestone id

Requirement: Exclude reimbursement system

The plan management delivery streams described in this change SHALL NOT require integration with the BX reimbursement subsystem for the current phase.

Scenario: No BX API dependency in M1 scope

  • WHEN M1 services are deployed
  • THEN the plan service SHALL operate without calling BX reimbursement endpoints