The Site plan

PLAN.md is written the moment a project's first build finishes, and it's meant to always describe the site as it is right now — not a log of everything that's ever happened to it (that's what the Versions tab and the Changelog are for). The Site plan screen parses that Markdown into real UI: a table for pages, a list for modules, a checklist for open questions, and plain prose for business facts, brand, and decisions.

Before any build has finished, there's nothing to read yet: the screen shows "No plan yet," explains plainly that the plan is written by the project's first build, and links back to the project's own page rather than showing an empty table.

At the top, once a plan exists: an overall percent-complete bar, and three tiles underneath it — Pages built (out of pages planned), Modules built (out of modules picked), and Questions answered (out of the plan's open questions). Each tile is a button: press it and the page scrolls to the section it counts, so every number is a door into the detail behind it. None of this is self-reported by the plan text itself: a page counts as built only when its planned path genuinely matches one of the project's real deployed files by name; a module counts as built only from the real, verified build report (the same grep-checked result the Build plan & files card uses — never just the AI's word that it built something); and a question counts as answered only when its line is written as a checked box or explicitly marked answered.

• Pages — a table: Page, Path, Purpose, and Status (Built or Planned), with a real "View" link to the live page once it's both built and the site is live.
• Modules and tools — every module the plan lists, each with a Built or Planned pill and its own note.
• Business facts — hours, address, services, prices, anything factual about the business, written as plain text.
• Brand — the palette, tone, and any style notes the plan has recorded.
• Decisions — real calls that have been made and shouldn't be re-litigated by the next edit.
• Open questions — a checklist of things still genuinely undecided, each showing answered or still open.

Every section card has the same two buttons. "Edit" opens that section's raw Markdown in a plain textarea and saves it directly back into PLAN.md — this is a genuine, immediate write (through the project's own PUT endpoint), but it deliberately does not trigger a build or a deploy; it only changes what the plan document says, the same as editing any other note.

"Ask for a change" is different on purpose: it opens a small form ("What would you like changed in <section>?"), and sending it files a real request onto the project's Feedback tab — labeled "Site plan — <Section>: …" — exactly like any pin or Quick edit request, with its own status lifecycle and a "View the request" link once it's sent. Use Edit when you're correcting or rewriting the plan's own text yourself; use Ask for a change when you want the actual site (and, in turn, the plan) updated to match.

This is the whole point of the Site plan being a living document rather than a snapshot: after every change that lands on the site — a chat edit, a pin fix, an area drawn and fixed — the build engine runs a dedicated plan pass (aikit-edit-engine's plan-log.js) that reads the current PLAN.md and rewrites only the parts the change actually affects — the page list, the modules, the business facts, the brand notes, the decisions — then restamps a single "Last updated" line at the top. It's explicitly told never to add a changelog, a dated entry, or a history; the plan is supposed to describe the site as it is now, once, not accumulate ten thousand small amendments.

If that model call fails for any reason, the plan is left exactly as it was rather than being partially or incorrectly rewritten — a slightly stale plan is safer than a corrupted one, and the next successful change catches it up again.

A rail beside the plan holds the actions (on a phone the rail becomes a full-width "Copy the client link" button right under the progress band, with the rest folded under "More actions (3)"). "Share with the client" copies a read-only link (aikit.ai/p/<project>/plan) — no staff tools, no edit buttons, nothing internal. "Open the live site" is a direct link to the live site, or the rail says plainly "Not live yet" if it isn't. "Files" shows the real file count with an expandable list of every file's path and size. "Download the plan" downloads the actual current PLAN.md as a real .md file, byte for byte what the screen is reading — not a regenerated summary.

At their own copy of the link, gated behind the same access code they already use to leave feedback (there's no separate login), a client sees nearly the same screen: the same progress band, the same six sections, the same pages table with the same real "View" links. Two things are different, deliberately. There's no Edit or Ask-for-a-change button anywhere — this is a read view, not an editing surface, so a change still has to go through a real request. And any line under Decisions that staff wrote with "(internal)" in it — a pricing floor, an internal hold-back, anything meant only for the team — is filtered out before the page ever renders it; everything else on the plan is shown to the client exactly as staff see it.

A "Send feedback" button sits at the bottom: if the site is live, it opens the real live site with the feedback overlay already turned on (using their own access code); if it isn't live yet, it falls back to their Recent updates page instead.