Skip to content

feat(design): an agent's publish is an approval - #842

Closed
mortondev wants to merge 1 commit into
feat/portal-design-v2-phase3-aifrom
feat/portal-design-v2-phase3-agents
Closed

mortondev wants to merge 1 commit into
feat/portal-design-v2-phase3-aifrom
feat/portal-design-v2-phase3-agents

Conversation

@mortondev

@mortondev mortondev commented Oct 30, 2026 •

Copy link
Copy Markdown
Member

The ninth of the stack that builds a new design engine for the portal. An agent can edit the portal design draft and ask a person to publish it; only a person's approval publishes. Behind the portalDesignV2 Labs switch, and the design tools are offered only while the portal uses the design engine.

Publishing is a request

publish_portal_design never publishes. It files an approval listing the draft's changes, each named as Appearance names it ("Accent", "Density"), and returns the approvals link. A person who may edit branding approves it on the approvals page, and exactly the draft they were shown goes live, recorded as theirs. If the draft changed after the request, the approval is refused with DRAFT_CHANGED and nothing is published; ask again. Asking again for the same draft returns the waiting request. The key that asked can never approve its own request.

The request takes no note: everything an approval shows is written by the server from the draft, never by the agent.

Home

Home edits the draft directly, since visitors never see a draft, and files a publish only when asked. Its prompt names the exception to "every change is a proposal". If the portal still uses the legacy theme, the design tools say so and Home points to Settings › Portal.

Approvals

A design publish shows its changes field by field, under Branding, and refreshes the design editor once approved. What a request shows (the diff on the page, and the title, summary and changes followers read) now lives in one module, approval-content.ts, for settings requests and design publishes alike.

Verification

  • Typecheck, lint and the server-function manifest check pass. The authz matrix gains the tool, gated by settings.branding, and the dependency graph the assistant → design edge.
  • New tests, each checked by breaking the code it covers: filing, reusing a waiting request, approving publishes exactly the requested draft, a moved draft is refused, who may decide, the approvals view and rejection (against the database); the MCP tool's permission, legacy refusal and errors; the approvals page rows; Home's prompt.

An agent edits the portal design draft and asks a person to publish it.
publish_portal_design files an approval listing the draft's changes, named
as Appearance names them; nothing goes live until a person who may edit
branding approves it, and then exactly that draft is published. A draft that
moved after the request is refused. Asking again for the same draft returns
the waiting request.

Home edits the draft directly, since visitors never see a draft, and files a
publish only when asked. The design tools are offered only while the portal
uses the design engine.
@mortondev

Copy link
Copy Markdown
Member Author

Condensed into #878. The stack is now five PRs, #878 to #882; this branch is kept as it was.

@mortondev mortondev closed this Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant