feat: guardrails: memory, workpad, auto review and Insights as one loop

AGENTS.md

@@ -24,6 +24,7 @@
 - A card's ordinary follow-up sends exactly the user's text after fresh task/workspace/session authorization. Give task context at session creation or through the explicit Kanban work-instructions action; do not prepend a task header to every message.
 - Card business status and session execution status are independent. A turn ending never automatically completes the card.
 - Automatic assignment, multi-agent handoffs, role orchestration, cross-host scheduling, and PR automation are outside v1.
+- Exception, user-approved 2026-10-27: with a project's *Auto review* on, an agent delivery to In review starts an automatic review. Flowly may run the project's configured check commands, create a temporary review session in the card's workspace (hard-deleted when done, like the summarizer), and, when the review fails, move the card back to the work stage it was delivered from and send a marked rework message to the delivering session, up to the project's rework limit; past the limit the card goes to Blocked. On for new projects, off for existing ones until the user turns it on (user decision 2026-10-28); a pass never moves a card to Done. See `docs/AUTO-REVIEW-SPEC.md` and `docs/GUARDRAILS-SPEC.md`.
 - Archiving plugin records preserves history and does not implicitly archive/delete Paseo resources or directories.
 - Exception, explicit only: the user-confirmed **Remove** of a project deletes it and its cards from plugin data (after writing a backup to `removed/`). Only when the user also chooses *Also remove from Paseo*, and no session in its workspaces is running, the native Paseo project is removed too (`paseo project delete`, which keeps every folder, worktree and branch on disk). See `docs/PROJECT-REMOVE-SPEC.md`.
 - Exception, explicit only: the user-confirmed **Delete permanently** of a card (any lane) deletes that card, its events, receipts and summaries from plugin data (after writing a backup to `removed/`). Only when the user chooses *Archive* in that dialog, or has *Auto archive on delete* on and the wrap-up preflight is clean, its sessions and its own workspace are archived first (running sessions block; warnings are shown). See `docs/TASK-DELETE-SPEC.md`.
@@ -57,7 +58,7 @@
 
 ## Onboarding upkeep
 
-- Every user-visible feature added or changed must update the new-user guidance in the same change (`docs/ONBOARDING-SPEC.md`): add or revise the matching welcome-tour copy in `client/onboarding.tsx` (concept map, loop, the Built in / Project memory / Insights pages with their switches, the More features list on the last page; `docs/ONBOARDING-SETUP-SPEC.md`) when the feature changes how Projects/Cards/Sessions map to Paseo, the basic loop, or a headline capability, and add a one-time tip (`tipIds` in `client/onboarding-logic.ts`, texts in `tipText` in `client/board.tsx`, priority in `nextTip`) when the feature has a moment worth pointing out. If neither is warranted, say so in the delivery note. Keep README highlights, tour copy and tips consistent, add every new string to all catalogs, extend `client/onboarding-logic.test.ts` for new tip rules, and update the spec's tip table.
+- Every user-visible feature added or changed must update the new-user guidance in the same change (`docs/ONBOARDING-SPEC.md`): add or revise the matching welcome-tour copy in `client/onboarding.tsx` (concept map, loop, the Built in / Guardrails / Insights pages with their switches, the More features list on the last page; `docs/ONBOARDING-SETUP-SPEC.md`) when the feature changes how Projects/Cards/Sessions map to Paseo, the basic loop, or a headline capability, and add a one-time tip (`tipIds` in `client/onboarding-logic.ts`, texts in `tipText` in `client/board.tsx`, priority in `nextTip`) when the feature has a moment worth pointing out. If neither is warranted, say so in the delivery note. Keep README highlights, tour copy and tips consistent, add every new string to all catalogs, extend `client/onboarding-logic.test.ts` for new tip rules, and update the spec's tip table.
 - A new tip id is not in anyone's stored `tipsSeen`, so it is shown once to every user, including existing ones: that is how new features get announced. Do not add it to a stored list. Existing users were only marked seen for the tip ids that existed at that time.
 - When a minor or major release (x.Y.0 or X.0.0) changes something existing users will not run into themselves (a new setting, a switch whose default differs for them, a moved entry point), add that release on top of `client/whats-new.ts` (its user-visible new features, one sentence each, at most 7, optional Open settings / Take the tour button; older releases stay, back to 1.5.0). Existing users see the newest release once after updating and can page back to older ones; new users skip it because the tour covers it (`docs/WHATS-NEW-SPEC.md`). Patch releases (x.y.Z) never add a What's new entry (user decision 2026-10-27).
 

README.md

@@ -58,7 +58,9 @@ After every completed turn a cheap model (Haiku 5.5 by default, configurable) up
 
 ![Card summary: state, target, recap and next step](docs/promo/screenshots/03-card-summary.png)
 
-Agents also keep a **Workpad** on the card: acceptance criteria, the checks they run (passed, failed or not run, each on a named commit, with the exact command) and what in the card confused them. Their plan comes from their own todo list. The card shows **Checks 3/5**; a check that ran on an older commit than the workspace's HEAD reads *out of date*. You can tick criteria and set a check's state yourself. Before they start, agents set the card's type and tags and write the workpad; until they do, every Flowly tool result reminds them. An agent delivering to In review with open items, or without a type, tags or workpad, has to acknowledge that with a note, and with open items the card then says **Delivered with N open items**. Turn it off per project with *Card workpad* in the project settings.
+Agents also keep a **Workpad** on the card: the acceptance list they write before they start (ticked as they meet each item; you can tick them too), what the card was sent back for, the latest review and their plan from their own todo list. The card shows **Acceptance 3/5**. Before they start, agents set the card's type and tags and write the acceptance list; until they do, every Flowly tool result reminds them, and delivering without them needs a note. Turn the acceptance list off per project with *Card workpad* in the project settings.
+
+**Auto review** (on for new projects; turn it on for an existing one in its settings or from What's new): when an agent delivers a card to In review, Flowly checks it before it reaches you. It runs the project's check commands (found in the repository, for example `npm test`; a newly found one only reports during its first three reviews), then a separate reviewer judges whether the change does what you asked on the card and in its sessions and whether it meets the project's guidelines. A failure sends the card back to the stage it came from with what fell short, in your own words; after the rework limit the card goes to Blocked. The card shows **Checked** or **Sent back**, and a strip under it follows the review while it runs. Checked does not mean right: Done is still your call. Each review uses tokens.
 
 ### 4. Follow-up ideas
 
@@ -67,7 +69,9 @@ Work an agent discovers along the way (a bug it tripped over, a limitation, the
 ![Ideas inbox with source cards](docs/promo/screenshots/04-ideas-inbox.png)
 ![Good idea: start a new task, continue in the session, or use a new session](docs/promo/screenshots/04b-good-idea-two-paths.png)
 
-What should outlive a card goes to **project memory**: decisions you made (including the options you turned down), pitfalls and dead ends, how you want work done, and the people and systems involved. Agents suggest entries with `flowly_remember`, and a cheap model reviews each card you move to Done and suggests at most one more, only when it holds beyond that card; nothing counts until you confirm it on the project's **Memory** page (`M`). Confirmed entries go into the first instructions of the project's new sessions (all of them while they fit, otherwise the pinned and most relevant ones; agents look up the rest with `flowly_recall`). You can edit, pin, archive or delete any entry, copy one as an `AGENTS.md` rule, and turn memory off per project. It is stored on your machine, never in the repository.
+**Guardrails** (`G`) are what the project checks, grown from the cards you send back. When you send a card back, Flowly notes what was wrong on that card; when a second card goes back for the same thing, it becomes a project guideline, checked on every later delivery it applies to. Each guideline shows your words, how often it caught, missed or misfired, and the kinds of change it applies to; one that keeps misfiring or never catches anything retires by itself, and comes back if the problem does. Next to them are the project's check commands. You can edit, pause, archive or delete any of it, and turn guardrails off per project.
+
+**Memory** (`M`) holds the project's decisions, pitfalls, conventions and contacts that agents save with `flowly_remember` or that the review of a finished card finds, and the ones you add. Memory takes effect at once in new sessions' first instructions (agents look up the rest with `flowly_recall`). Filter by kind, sort by newest or most used, switch between a list and a grid, pin, edit, archive, or copy one as an `AGENTS.md` rule. Guardrails and memory are stored on your machine, never in the repository.
 
 **Search** (`S`, or the search button) looks through past cards: titles, summaries, progress notes, workpads, ideas and deliverables, so pasting a PR link or a Jira key finds the card behind it. It covers the current project or all of them, and runs on your machine. Agents search the same history with `flowly_search` when they start on an area.
 
@@ -93,7 +97,7 @@ Insights shows a year of the project's activity, GitHub style: one square per da
 </details>
 
 
-**Skills** (on by default, turn it off in the welcome tour or Settings → AI features): every week a model you choose reads the project's cards (summaries, acceptance criteria, your own corrections kept by project memory), confirmed memory and the redacted shell commands agents ran, and drafts complete skills, a procedure agents did differently each time (shipping through a pull request and waiting for review) or what several cards of one kind taught (plugin performance). **Add to project** writes `.agents/skills/<name>/SKILL.md` (read by Codex) and links it from `.claude/skills/<name>` (read by Claude Code); nothing is committed for you. Later runs propose updates to the skills Flowly added, shown as a diff. The same run still suggests `paseo.json` scripts, worktree setup, repo tools and AGENTS.md rules; each becomes a card with one click. Each run replaces the drafts nobody acted on; quiet weeks are skipped without calling the model, and the first scheduled run waits one full period. Agents see the project's `paseo.json` scripts in their task context.
+**Skills** (on by default, turn it off in the welcome tour or Settings → AI features): every week a model you choose reads the project's cards (summaries, acceptance criteria, your own corrections), the project's notes and guidelines and the redacted shell commands agents ran, and drafts complete skills, a procedure agents did differently each time (shipping through a pull request and waiting for review) or what several cards of one kind taught (plugin performance). **Add to project** writes `.agents/skills/<name>/SKILL.md` (read by Codex) and links it from `.claude/skills/<name>` (read by Claude Code); nothing is committed for you. Later runs propose updates to the skills Flowly added, shown as a diff. The same run still suggests `paseo.json` scripts, worktree setup, repo tools and AGENTS.md rules; each becomes a card with one click. Each run replaces the drafts nobody acted on; quiet weeks are skipped without calling the model, and the first scheduled run waits one full period. Agents see the project's `paseo.json` scripts in their task context.
 
 ## Languages
 
@@ -105,7 +109,7 @@ The interface follows your device language, or pick one in **Flowly settings →
 
 ## Quick start
 
-The first time you open Flowly, a short welcome tour explains projects, cards and sessions and sets the basics: interface and AI output language, the progress model, whether progress, next steps and ideas also apply to sessions outside Flowly (on by default; each of their turns then runs the summary model once), and whether Project memory and Insights are on. Skip keeps the defaults. Change any of it later from the gear at the bottom left.
+The first time you open Flowly, a short welcome tour explains projects, cards and sessions and sets the basics: interface and AI output language, the progress model, whether progress, next steps and ideas also apply to sessions outside Flowly (on by default; each of their turns then runs the summary model once), and whether Guardrails and Insights are on. Skip keeps the defaults. Change any of it later from the gear at the bottom left.
 
 1. **New project**: pick a directory (or several repositories) to register as a native Paseo project.
 2. **New task**: describe the work; optionally start an agent together with the card.