Policy — Deploy Feedback

After any deploy or publish operation, Claude must report back to the user with a *lickable URL*so the user can verify the result in a browser.

Rules

1. URL After Deploy

Whenever a web application is updated or deployed, write the *ull URL*(e.g. https://flow.koder.dev) in the chat so the user can click it and open in a browser to test.

2. Landing Pages — Publish and Report URL

Whenever the user asks to create or modify a landing page, after finishing the changes:

1. *utomatically publish/deploy*the landing page to the server.
2. *rite the URL*in the chat so the user can open it and see how it looks.

3. Icons in Landing Pages — Publish and Report URL

Whenever an icon is created or changed and that icon is being used in a landing page, after finishing:

1. *utomatically publish/deploy*the updated landing page.
2. *rite the URL*in the chat.

4. VisuallyEvaluated Changes on Any AlreadyPublished Web Page

Whenever Claude modifies an object, style, copy or layout on a web page that is *lready deployed*and the user's evaluation depends on *eeing*the result rendered (visual regression, alignment, colour, spacing, animation timing, etc.), Claude must, without asking:

1. *ommit and publish/deploy*the change to the same environment

   that the user is looking at (typically prd when the URL is the canonical production host; stg/dev only when the user is explicitly inspecting that environment).

2. *rite the clickable URL*in the chat — including the locale prefix

   and any sub-route — so the user can refresh and evaluate.

3. *ell the user to hard-reload*(Ctrl+Shift+R / Cmd+Shift+R) if

   the asset is cachebusted by a longlived Cache-Control header.

Applies to (non-exhaustive): landing pages, design system site (kds.koder.dev), web apps (<product>.koder.dev), admin dashboards, docs sites, Hub package pages, marketing pages.

*oes not apply*to (no auto-publish):

• Backend-only changes with no visible surface in the current session.
• Library / SDK / engine edits that ship via release of a downstream

  consumer (release flow takes over — see policies/releases.kmd).

• MobiledesktopTV native UI (no public URL — needs /k-reinstall or

  local emulator instead; that flow has its own feedback path).

• Internal-only environments the user has not opened in this session.

Rationale: asking "want me to deploy so you can see?" after every visual edit adds a turn of friction for a yes that is the only sensible answer — the user only asked about the look because they want to look at it.

Why

Deploys without a reported URL force the user to manually assemble the URL, open a terminal, or guess where the change landed. A clickable URL is zero-friction verification.

Anti-patterns

• Saying "deployed successfully" without the URL.
• Reporting just the relative path (e.g. site/index.html) without the public URL.
• Reporting a URL that doesn't exist yet (false positive).