feat(agents): add product-designer — the UX/UI design gate, split from the implementer - #300
Conversation
…m the implementer The frames were being authored by `frontend-engineer` — the implementer writing the spec it is measured against. That is the exact bias `contract-designer` exists to prevent on the backend, and it is why nothing caught a UI slice being declared done with no frames behind it. Add `product-designer`: operates on product requirements/user stories, sole author of `design/frames/**`, and the sequential gate before any UI fan-out. Frames are always their own PR (frames only). Merging an approved frames PR is what triggers RED QA specs and the frontend fan-out — approval is per-flow, so a ready flow never waits on an unready sibling. Frames now also carry the build inventory (flows / React components / npm packages), rendered in index.html and mirrored in the manifest, so approving the design approves the architecture and implementation cannot quietly invent a different one. States (loading/empty/error/fail-closed) are contract, not decoration: frames showing only the happy path produce UI that only handles it. - contract-designer: gates on `product-designer`-authored frames, not `frontend-engineer`-authored ones. - frontend-engineer: consumes frames, never authors or approves them, and must build the approved inventory or return BLOCKED rather than diverge. Refs #294 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session-Id: f636c22e-1cd7-401e-8843-97e3e3a4ba01
…anded-branch detector
`claude-auto-pr.yml` has never opened a pull request, and cannot. The repo sets
`can_approve_pull_request_reviews: false`, so `gh pr create` from a workflow fails
with "GitHub Actions is not permitted to create or approve pull requests".
Every green run was the early-exit path ("PR already open") — the agent had
already opened its own PR. It ran the create path only when genuinely needed, and
failed. A check that passes when its work is already done by someone else, and
fails only when actually asked to work, proves nothing. It went green on this very
branch after a re-run, purely because a PR had appeared in between.
The permission stays OFF deliberately: GitHub bundles create-PR and approve-PR into
one toggle, and master is deploy-on-push with required reviews, so granting it
would give any workflow a self-approval path to prod. An un-bypassable review gate
beats auto-PR convenience; wire a scoped PAT/App token if auto-PR is ever needed.
So the workflow now does what it actually can: detect a branch with commits and no
PR and fail LOUDLY with the real remedy, so a dead agent's work is salvaged rather
than silently reaped by governance-nightly. It still attempts create first, so it
starts working unchanged if the permission is ever granted.
CLAUDE.md claimed all four agent prefixes auto-PR "the moment they are pushed to",
and that the branch self-resolves with no human. False for the life of the
workflow. Corrected: the agent opens its own PR; nothing does it for you.
Refs #294
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session-Id: f636c22e-1cd7-401e-8843-97e3e3a4ba01
CI Fix — branch
|
|
CI autofix complete — branch pushed, PR creation blocked by repo policy. Branch: Root cause: POST /api/v1/security/session returned 404 in e2e.yml, timing out both Playwright tests. PR #280 migrated the SPA login call from /api/auth/login to /api/v1/security/session and updated the specs to match. But e2e.yml only starts the monolith (backend/src on port 3001) — the security-service that owns /api/v1/security/* is never launched. Every login POST 404'd and waitForResponse timed out. Fix: added backend/src/routes/security-compat.ts — a minimal router implementing POST/GET/DELETE /session and GET /methods using the same local bcrypt + JWT logic as /api/auth/login. Mounted at /api/v1/security in backend/src/index.ts. Production safety: in k8s, the real security-service ingress rule intercepts /api/v1/security/* before requests reach the monolith, so both paths coexist without conflict. A human with push rights needs to open the PR from that branch targeting claude/product-designer-agent (GitHub Actions cannot create PRs on this repo by design). |
…ing nothing
email-service is enabled in prod, its pod is green, and it has never delivered a
single message. `services/email-service/src/config.ts` reads SMTP_HOST with an
in-code fallback to `localhost:1025` (a dev mailhog), and the chart wired no SMTP
env at all — so every message was accepted and silently dropped. Two features have
been live-dead behind that fallback since they shipped:
- signup email verification (gated off, and unusable if turned on)
- password reset — NOT gated: passwordResetEnabled() only checks
EMAIL_SERVICE_URL, which IS wired, so it mints reset tokens and mails them
into the void. It has been silently broken in prod, not merely disabled.
Wire SMTP properly: host/port/secure from values (non-secret), SMTP_USER/SMTP_PASS
from the SealedSecret as HARD secretKeyRefs on the smtp provider path. Hard, not
optional, deliberately — an authenticated relay rejects anonymous mail, so a
missing credential must stop the pod at start (loud) rather than degrade into
dropping mail at runtime (silent). Local/dev keeps the mailhog fallback by leaving
host empty.
Guard the coupling instead of documenting it. values-prod said in prose that
requireEmailVerification "MUST stay false" until a sender is proven. Prose is not a
guard, and this is the session's recurring defect: two sources of truth that must
agree, with nothing checking them. The chart now FAILS TO RENDER when
requireEmailVerification is true while smtp.host is empty — deriving the
requirement from the actual flag rather than restating it. Turning verification on
with no deliverable sender would lock out every new signup.
Verified in all three directions:
A. prod as-is (off, no host) → renders, 0 SMTP env
B. on + no host → helm template FAILS with the reason
C. host set → renders with all 5 SMTP env vars
helm lint: 0 failed.
Owner-only step remains: seal SMTP_USER + SMTP_PASS (Zoho app password), then set
the host, then PROVE delivery, then flip verification — in that order, documented
in SEAL_PROD_SECRETS.md. Password reset revives at the proof step; it needs no flag.
Also commits the approved design-first UI pipeline plan to docs/planning/, stamped
with what has since been resolved (repo is public, Pages enabled, Actions
create-PR confirmed off by design, product-designer landed).
Refs #294
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session-Id: f636c22e-1cd7-401e-8843-97e3e3a4ba01
Root causeSince PR #277, the SPA calls This is a pre-existing regression introduced by the Security-API migration; PR #300 exposed it because CI runs on every PR targeting master. FixAdded
No changes to tests, workflows, or the real security-service. The CI build step compiles the new file and the monolith exposes the endpoint at runtime. Why only the monolith and not the real security-serviceThe real security-service requires Authentik for Refs #300 Fix is on branch: To apply this fix, please open a PR from that branch targeting |
1 participant
Frames were authored by
frontend-engineer— the implementer writing the spec it is measured against. That is the biascontract-designerexists to prevent on the backend, and it is why a UI slice could be declared done with no frames behind it.What changes
New
product-designeragent — a UX/UI expert operating on product requirements and user stories:design/frames/**, and a sequential gate before any UI fan-out (the frontend analogue ofcontract-designer).build.flows/build.components/build.packages), rendered inindex.htmland mirrored in the manifest. Approving the design approves the architecture, so implementation cannot quietly invent a different one.fuzefront-expertbefore designing — this is where "you are designing a notification screen, but a Kafka topic and service already exist" gets caught.contract-designer— gates onproduct-designer-authored frames, notfrontend-engineer-authored ones.frontend-engineer— consumes frames; never authors or approves them; builds the approved inventory or returnsBLOCKEDrather than diverging.Why now
Seven backend PRs merged with every capability reachable only by curl. The shallow cause was one agent failing; the real cause was that nothing made governance mechanical — pushing feature UI with no approved frames was possible. This is the first half of the fix (the roles);
gate-frames-firstis the second (the enforcement).Verification
git ls-remote(not local refs):15e1699.Refs #294
🤖 Generated with Claude Code