mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add decision traceability governance

Browse Source
This commit is contained in:
Codex
2026-05-22 07:19:30 +00:00
parent fcf2bc1826
commit 5481a0ce9d
4 changed files with 23 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/user-service-delivery.md
+3
View File
@@ -60,6 +60,8 @@ The current catalog covers `frontend`, `baidu-netdisk`, `decision-center`, `proj
Many user services are surfaced through the UniDesk frontend rather than through their own browser-exposed product. When a user-service backend has a paired UniDesk frontend page, the frontend change must be validated in the same dev/prod release window as the backend artifact. The frontend itself is also a reviewed artifact producer/consumer sample: its release unit is `127.0.0.1:5000/unidesk/frontend:<commit>`, and the live UI must expose the same requested commit through image labels and `/health.deploy.commit`.
The paired frontend's default route must continue to expose the real user workflow. Diagnostics or status surfaces may exist for verification and recovery, but they must stay explicit secondary routes and must not replace the default product entry. The traceability record for this boundary is `DC-DCSN-P0-2026-004`.
## Frontend
Frontend is the canonical user-service UI sample. It is not released by target-side source build as the standard path.
@@ -152,6 +154,7 @@ Decision Center is the canonical example of a user service that doubles as a pro
- Before any production deploy, the dev gate must pass first with the focused Decision Center E2E set covering `microservice:decision-center-record-crud`, `microservice:decision-center-diary-lifecycle`, `frontend:decision-center-visible`, `frontend:decision-center-demand-management-visible`, and `frontend:decision-center-diary-visible`; this is an automated user-service validation gate, not a production deploy.
- Document-management changes must first land in the D601 dev Decision Center service and extend the focused E2E set with doc-number creation/upsert/list/detail uniqueness, migration/backfill, frontend visibility and temporary body-prefix compatibility before production rollout.
- Production acceptance is manual after the dev gate and must explicitly verify `health`, `records`, `diary editor`, the paired frontend page, no public business ports, and live commit / artifact information.
- Acceptance notes may cite diagnostics/status pages as evidence, but those pages must be labeled as diagnostics and not as the default user workflow.
Detailed service-level API and UI contracts remain in `docs/reference/microservices.md`.