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.

A site whose files came in without a plan (published from another AI tool through the connector, imported, or uploaded) still gets one: the screen starts the plan from the project brief, the kit picks and the measured pages, and a banner, This plan was started for you, offers Save this plan, which makes it the project's real plan so every section can be edited. Read the full site plan goes back to the plan document on the Plan & brief tab.

Tools added later from the Kit (Add to plan) join the Modules list as Planned with a View in the Kit link, even when the plan text was written before they were added.

Under the title, one line says when the plan was last brought up to date: "Plan updated Oct 2, 3:04 PM". That time comes from the last time aiKit measured the site's real files, which happens after every change (a chat edit, a pin, a kit add, a restore, a hand edit of the plan, a publish from another AI tool).

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 that scrolls to the section it counts. None of this is self-reported by the plan text: a page counts as built only when aiKit found it in the site's real files; a module counts as built only from the verified build report or the module found in the files; and a question counts as answered when its line is checked off in the plan or the client answered it on their Questions page.

Two things make the plan fall behind, and the screen says which one: the AI pass that rewrites the plan after a change did not finish ("The written plan didn't update after the last change," with the reason), or the site has a newer version than the plan was measured against ("The site changed after this plan was last updated"). In either case a "Refresh plan" button appears. The page never runs it on its own when you open it (opening a page never uses AI); the engine already folds each change into the plan in the background, and the button is there for when that fell behind. Refresh plan folds the newest change into the written plan and measures the site again. If it still does not go through, the banner stays with what went wrong, and you can press Refresh plan again or edit the plan by hand.

The Health card scores the site out of 100 from rules aiKit checks in the real files, never from the AI's opinion: a missing or repeated page title or search description, a page with no main heading or more than one, a link to a page that does not exist, a page nothing links to and the menu leaves out, pictures without a description for screen readers, very short pages, a form with nowhere to send, and a module the brief asked for that is not on the site. Each issue says which page, why it matters, and has a Fix button: Fix files the issue's ready-made instruction as a request and hands it to the AI, the button shows "Fix requested" while it works, and the score is measured again when the change lands. Filter the list by severity with the High, Medium, and Low counts, and "Show all" clears the filter.

The Sitemap draws the site as a tree: home at the top, then the menu in order, then pages reached from those pages. Pages nothing links to sit in their own group, pages the plan lists that are not built yet are drawn dashed and marked Planned, and built pages the plan never mentions are marked "Not in the plan" with an "Add to plan" button that adds them to the Pages section.

Press any page (in the sitemap or the Pages list) to open its details beside the plan. The address bar changes to ?page=/about, so the link opens the same page for anyone on the team. Details show how the page looks in Google (title, address, description), its sections and main headings, word count, pictures and how many lack a description, its forms and which kit module runs them, whether the client approved it, and the last change: when, who asked, and what they asked for.

History lists the versions aiKit keeps (the Original and the newest 10), newest first: its number, what kind of change it was (First build, Chat, Pin, Kit, Published, Restore, Plan edit), when, what was asked, who asked, and which pages changed (press a page to open its details). The newest is marked Current version; any older one has "Restore this version," which asks first and saves the current state before putting the site back, so a restore can be undone. The first three show; "Show all" lists the rest.

The Business facts section compares the phone, email, address, and hours in the Client File with the text of the built pages (home and contact first). Each fact shows "On the site" or "Not found on the site" (with how many pages were checked, since the site may show an old value), and an "Edit in the Client File" link keeps the Client File as the source of truth.

• 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.

The plan has two layers. The measurements (pages, titles, sections, links, forms, modules, health) are taken by code from the real files after every change, so they cannot drift. The written plan (goals, business facts, brand, decisions, open questions) is kept current by an AI pass that runs after each change and rewrites only the parts the change touched. It never adds a changelog or dated entries; History is where the record of changes lives.

If that AI pass fails, the written plan is left as it was rather than half-rewritten, the failure is recorded, and the screen shows Refresh plan (see above) instead of quietly showing an out-of-date plan.

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.

The client's page opens on its Plan tab: the same site plan document staff see on the Plan & brief tab (overview and goals, audience, strategy, sitemap, every tool with what it does for their business and its status, content plan, timeline, decisions and open questions), without the staff-only parts: no notes typed when a tool was added, no names of who added what, no links into aiKit's Kit, and no Write the plan button. A second tab, Pages & approvals, keeps the page-by-page view below.

On Pages & approvals, gated behind the same access code they already use to leave feedback (no separate login), a client sees the same progress band, a Sitemap of their pages, the Pages list with "View" links, the modules, business facts, brand, decisions, and open questions, plus a "Plan updated" line. They do not get Health, fix instructions, History, who asked for what, the file list, or any Edit or Ask-for-a-change button.

Anything staff mark for themselves is removed on the server before the page is sent, in every section: a line containing "(internal)", "[internal]" or "(staff only)", a line starting "Internal:" or "Staff only:", any section whose heading says Internal or Staff only, and hidden comments. Those lines never reach the client's browser at all, not even in the page's network data.

Each built page has an Approve button. The client types their name (and an optional note) and approves; the approval is tied to that page's exact content, so if the page changes later it shows "Changed since you approved" and asks again. Only someone using the client's access code can approve. If you open the client link while signed in as staff, you see each page's approval state but no Approve button, so nobody can approve on the client's behalf. On the staff Site plan, approved pages show "Client approved" and changed ones "Changed since approval."

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.