feat: standardize user service artifact producer

2026-05-19 10:05:15 +00:00
parent e866b0526a
commit 292d0cee60
4 changed files with 588 additions and 7 deletions
@@ -32,6 +32,8 @@ The default release flow for a user-service change is:
 - No user-service artifact may rely on a third-party registry as source of truth.
 - No production deploy may rebuild the source from a dirty worktree.
 - Commit-pinned image tags are the deployment truth; mutable `latest` tags are not.
+- The standard CI artifact producer is `bun scripts/cli.ts ci publish-user-service --service <id> --commit <full-sha>`. It accepts only a pushed Git commit and a registered service id, and reports image ref, tag, digest, source commit and service id.
+- The CI artifact producer is not a deploy executor. It must not mutate the production namespace, restart production services, or update `deploy.json`.
 - Every production release must finish with a manual acceptance step after the automated checks pass.

 ## Frontend Pairing
@@ -42,10 +44,14 @@ Many user services are surfaced through the UniDesk frontend rather than through

 Decision Center is the canonical example of a user service that doubles as a product workflow for requirements, decisions, and daily work diaries.

+- The minimal standard artifact command is `bun scripts/cli.ts ci publish-user-service --service decision-center --commit <full-sha> --wait-ms 1200000`.
+- The expected artifact is `127.0.0.1:5000/unidesk/decision-center:<commit>` plus its registry digest from the CI output.
 - Requirements and follow-up items should be represented with structured records such as `goal`, `decision`, `blocker`, `debt`, and `experiment`, with linked evidence and goal references.
 - The service should act as a demand-management surface for external goals that need to be decomposed into internal tasks, blockers, and decisions.
 - The work-diary surface should support creating today's diary entry automatically from the real current date.
 - Historical diary entries should be editable by date, with PostgreSQL remaining the source of truth.
 - The resulting product surface should stay structured and reviewable, not collapse into an untracked chat log.
+- 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.
+- 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.

 Detailed service-level API and UI contracts remain in `docs/reference/microservices.md`.