living-ui-modify

Living UI Modify

You are changing an EXISTING app. Everything in the living-ui-creator skill applies (ownership rule, schema/verbs/UI order, kit usage, honesty rule) — this skill covers only what differs.

Step 0: Locate and understand

1. Find the project: read agent_file_system/workspace/living_ui_projects.json or use the project id/path given in your instruction.
2. Read the project's LIVING_UI.md (current plan/entities/ops) and reference/requirements.md. Read manifest.json for authMode and port.
3. If something broke, read the logs FIRST: {project_path}/logs/frontend_console.log and {project_path}/logs/pocketbase.log.
4. If the request is ambiguous, ask 1 batch of clarifying questions (a FINAL send_message (continue_work=false — the reply wakes the session)).
5. Record the request in the spec BEFORE editing code: append a dated entry to reference/requirements.md under a ## Changes section (create the section if absent): - 2026-08-05: <the user's request, stated as a checkable capability>. NEVER rewrite the existing sections — they are the delivered contract; ## Changes is append-only. The verifier checks every entry there, so an unrecorded change is an unverified change (and a recorded one can never be silently dropped by a later modify). SUPERSESSION — the one permitted edit to old entries: when the new request REVERSES or REPLACES an earlier ## Changes entry (the user changed their mind, or the old entry demanded an approach the platform now rejects), wrap the stale entry in ~~strikethrough~~ — do not delete it (it stays as history) and do not leave it live (the verifier enforces every unstruck line, and contradictory live entries make the spec unsatisfiable: an app once went STUCK three times because old entries demanded a handler the validation gate forbids while the new entry forbade it — no code could satisfy both). Strike ONLY entries the new request genuinely contradicts, never entries you merely failed to build.