greenfield 0.0.52: publish the Session's pages to the destination before opening them

.agent-farm/workspace.yaml

@@ -17,9 +17,10 @@ instructions: |
   explicitly to discovery and creation tools.
 
   Folder: when an orchestrator supplies a Pane Session name, use
-  "sessions/<session-name>"; if another Session already uses that folder, append
-  the Session's short ID. Without an orchestrator, use
-  "Development Artifacts/DCouple/agent-farm".
+  "sessions/<session-name>"; if that folder already holds another Session's
+  status page, use "sessions/<session-name> · <short ID>", where the short ID is
+  the first 8 hex characters of the UUID in the Session's stable id. Without an
+  orchestrator, use "Development Artifacts/DCouple/agent-farm".
 
   Treat docs=grain as the default for every bundle. tmp/greenfield/ is only the
   local working copy; a bundle that exists only there is not delivered.

plugins/greenfield/README.md

@@ -94,7 +94,7 @@ Every bundle includes `trace.html`, emphasizing user/agent messages with tool ca
 
 One work item has one bundle: `index.html` (brief/hub), `options.html`, `cover-sheet.html`, `mockups/`, `explainers/`, `evidence/`, and `bundle.json`, as needed. The cover sheet is read by people, implementers, and reviewers. Use relative links and preserve the published identity on updates.
 
-Destinations follow the conversation, then the `docs` argument, then standing workspace/repository preferences, then local `tmp/greenfield/<slug>/`. The plugin names a destination service in one place only: the orchestrator's Session artifact, which goes to Grain as one private artifact opened beside you when Grain is the resolved destination. Everything else follows the repository: one that publishes to Grain, for example, says so in its committed `.agent-farm/workspace.yaml`, and a standing preference there publishes the same private artifact; a local working copy alone is not delivery. See `skills/page/references/bundle.md`.
+Destinations follow the conversation, then the `docs` argument, then standing workspace/repository preferences, then local `tmp/greenfield/<slug>/`. The plugin names no destination service. Each repository names its own in its committed `.agent-farm/workspace.yaml`, and a local working copy alone is not delivery. See `skills/page/references/bundle.md`.
 
 An orchestrator passes the planner its source as `source` and a status JSON path as `parent`, and gives the implementer and reviewer the same in their starting message. Workers record stage, checks, evidence, assumptions and blockers there. A worker that needs the person writes a numbered `needs_you` block (Q-n, kind, options with the recommended one first, why, files); the orchestrator relays it labelled with the role and feature, opens the files beside you, records your answer as a D-n and sends `answer: Q-n → …` to that worker only. In Pane, a worker asks a blocking question itself as a Notify card, so you answer it on the card; the orchestrator then numbers and records it and sends `recorded: Q-n → …`. Run by hand, workers ask you directly in the same shape. Legacy plans are inputs, not a requirement to generate new planning files. Trivial unplanned work retains the `no-plan` PR label.
 
@@ -129,7 +129,7 @@ Launch the Codex coordinator with `agent-farm run greenfield/orchestrator:codex
 3. Optionally, when you turn it on, `greenfield/simplify-and-refactor:sol` runs on each finished PR before QA and review, and applies only the plan you approve.
 4. A planned feature's implementer always runs full validation (CI, QA) when its build is done, and then its review starts on its own; a quick fix or tweaked PR is reviewed when you say it is "ready"; a cover sheet with `Human review: required` (the default when the plan changes UI) opens the PR beside you instead and waits for your "ready". Tweaks and quick fixes are committed to the PR, quick-verified with screenshots, and start no review. `greenfield/reviewer:codex` (GPT-6.1 Sol, max) reviews `<last reviewed head>...HEAD` and posts one reconciled `COMMENT` review, without applying fixes. Must-Fixes go to the owning implementer with no question, small in-scope Should-Fixes ride along only in a round a Must-Fix opened, approach/scope-flagged and out-of-scope findings come to you (re-plan, fix it here anyway, or accept), and a follow-up checks only the items sent. Each PR gets a fix-round budget from its size (small 1, standard 2, large 3) that QA and review fix rounds share, shown as "Fix rounds 1 of 2" on its card; the loop ends when a review says `Mergeable as is: yes`, and pauses to ask you (more rounds, re-plan, or accept) when the budget is spent with a Must-Fix open or a fix causes a new Must-Fix. Quick fixes and tweaks run `deferred` by default: local checks, quick-verify and push, with CI, QA and review waiting for your "ready". When you wrap up (type /wrap-up or say "wrap up" in Pane), the orchestrator first tells you about anything that needs attention, listing each PR with unreviewed commits, then archives every Pane that is safe to archive; the Session stays open for you to archive. A listed PR stays open and unreviewed until you say "ready" for it, and the orchestrator never calls a PR mergeable while it has unreviewed commits. Say "full" to validate a quick fix as you go; headless runs validate `full`. You can skip review, add checkpoints, or review each plan; the current policy shows on the map.
 
-The orchestrator keeps one status page (the workstream map) per Session, drawn by a bundled renderer (`orchestrate-sessions/assets/status-page/render.mjs`, Node only) from a status JSON (`<Session folder>/.agent/status.json`) to `<Session folder>/session/index.html`. In Pane it shows in the Session's Overview tab; elsewhere the orchestrator opens it beside you at the first dispatch. It leads with a short summary, the next step, one pointer saying how many questions wait for you in Approvals (in the orchestrator's chat outside Pane) with their Q-ids, never their wording, and tiles with a progress bar counted from the items. Then comes one card per item in flight with a rail of the steps the work actually took and its next step; clicking a card opens that item's own page (`session/items/<id>.html`), generated in the same run for every item, planned or not: what you asked for, what changes, where it stands, and a row each for its plan or task, PR, QA, review, worker, trace and post-mortem, with its siblings and a way back up. In Pane each Q-id links the tab holding its card, which opens Approvals on it. Completed items move to Done and keep their page, decisions collect in Decisions, and the order of work appears with two or more items. Sources and Relevant links, grouped by kind of work, link every document, PR, review and reference the work produced or relied on. The orchestrator writes it at the Session's first working turn, even when nothing is dispatched, rewrites it after every ledger write (its watcher re-renders a page that has fallen behind), the page reloads itself every minute, and every progress message ends with "Next: …". The local file is the canonical page; a published copy lives in one Session artifact at `sessions/<Session name> · <first 8 characters of the Session id>` in the document destination, reused for the Session's life; with no destination the Session's pages stay as local files in the Session folder, with one notice line saying so. Before dispatching into a repository it resolves that repository's workspace instructions (`agent-farm inspect greenfield/<profile> --directory <repo>`) and passes their document destination and the Session name to the worker. When a Session spans destinations, the map lives with the first repository's destination and links to short stub hubs in the others. It collects a trace of every session it launched whose repository's workspace instructions (or you) grant conversation capture, a labeled status page for the rest, and archives a feature's Pane without asking once its PR is merged or closed or its plan is abandoned, after a `--dry-run` shows the worktree is clean and pushed, and right after a merge you asked for. It closes the tabs it opened once they stop mattering; plans, PRs and mock-ups are linked from the status page rather than opened. Reviews, fixes and QA never get their own Pane; they run as tabs in the feature's Pane. It never passes `--force` and never deletes remote branches.
+The orchestrator keeps one status page (the workstream map) per Session, drawn by a bundled renderer (`orchestrate-sessions/assets/status-page/render.mjs`, Node only) from a status JSON (`<Session folder>/.agent/status.json`) to `<Session folder>/session/index.html`. In Pane it shows in the Session's Overview tab; elsewhere the orchestrator opens it beside you at the first dispatch. It leads with a short summary, the next step, one pointer saying how many questions wait for you in Approvals (in the orchestrator's chat outside Pane) with their Q-ids, never their wording, and tiles with a progress bar counted from the items. Then comes one card per item in flight with a rail of the steps the work actually took and its next step; clicking a card opens that item's own page (`session/items/<id>.html`), generated in the same run for every item, planned or not: what you asked for, what changes, where it stands, and a row each for its plan or task, PR, QA, review, worker, trace and post-mortem, with its siblings and a way back up. In Pane each Q-id links the tab holding its card, which opens Approvals on it. Completed items move to Done and keep their page, decisions collect in Decisions, and the order of work appears with two or more items. Sources and Relevant links, grouped by kind of work, link every document, PR, review and reference the work produced or relied on. The orchestrator writes it at the Session's first working turn, even when nothing is dispatched, rewrites it after every ledger write (its watcher re-renders a page that has fallen behind), the page reloads itself every minute, and every progress message ends with "Next: …". The local file is the working copy and the one Pane's Overview tab shows. When the workspace instructions name a document destination, the pages are also published there, even when the host says to keep documents local, to one Session artifact in the Session's folder: `sessions/<Session name>` unless the workspace instructions give another rule, with the short id added only when that folder already holds another Session's status page. It is published before it is opened and reused for the Session's life; if publishing fails, you see the local copy with one line saying so, and it retries at each refresh; with no destination the Session's pages stay as local files in the Session folder, with one notice line saying so. Before dispatching into a repository it resolves that repository's workspace instructions (`agent-farm inspect greenfield/<profile> --directory <repo>`) and passes their document destination, the Session name and the settled Session folder to the worker. When a Session spans destinations, the map lives with the first repository's destination and links to short stub hubs in the others. It collects a trace of every session it launched whose repository's workspace instructions (or you) grant conversation capture, a labeled status page for the rest, and archives a feature's Pane without asking once its PR is merged or closed or its plan is abandoned, after a `--dry-run` shows the worktree is clean and pushed, and right after a merge you asked for. It closes the tabs it opened once they stop mattering; plans, PRs and mock-ups are linked from the status page rather than opened. Reviews, fixes and QA never get their own Pane; they run as tabs in the feature's Pane. It never passes `--force` and never deletes remote branches.
 
 Host-injected instructions own the mechanics; Greenfield owns roles, approvals and review policy. A standalone launch can pass `--arg host_policy=/absolute/path/to/host-guidance.md`; this is an instruction document, not a runtime adapter. The orchestrator acts on host events and, while work is in flight without guaranteed events, offers a watcher and starts it if you don't answer. It proves the watcher fires, checks at 5, 10, 15 and 30 minutes (three times each, resetting to 5 on any change), relays any new `needs_you` it finds, and expires after three quiet 30-minute checks. It sizes concurrency to free disk and machine load before a fan-out; on each check it also confirms the host answers and disk is free, holds new workspaces and archives finished ones when space runs low, and tells you once when the host is down. When `greenfield/reviewer:codex` refuses a review on a content filter or policy, it reruns that review on `greenfield/reviewer:claude` and notes the swap on the PR's card. Urgency never implicitly enables fast mode. The orchestrator never edits project code and never pushes to a default branch. It merges a pull request only when you explicitly ask for that pull request, after telling you its state in one line (draft, CI, review).
 

plugins/greenfield/instructions/coordination.md

@@ -1,10 +1,10 @@
 # Coordination
 
-Route authorized work to a planner, then an implementer, then a reviewer, each a fresh agent in that feature's one workspace, and keep one status page (the workstream map) per Session. How to fill and render it is in `orchestrate-sessions`' `references/status-board.md`: read it before you first write it in a Session and again before any rewrite, and never write it from memory or from this paragraph. Write it at the Session's first working turn, even with nothing to dispatch, and rewrite it after every ledger write; in Pane it shows in the Session's Overview tab, and elsewhere you open it beside the person at the first dispatch and refresh it in the same tab. Always end every progress message to the person with "Next: …". In Pane, 1 feature = 1 worktree = 1 branch = 1 Pane; reviews, audits, fixes and QA for it are tabs in that Pane, opened with `runpane panels create --pane <id>`, never a new Pane. Use `orchestrate-sessions`.
+Route authorized work to a planner, then an implementer, then a reviewer, each a fresh agent in that feature's one workspace, and keep one status page (the workstream map) per Session. How to fill and render it is in `orchestrate-sessions`' `references/status-board.md`: read it before you first write it in a Session and again before any rewrite, and never write it from memory or from this paragraph. Write it at the Session's first working turn, even with nothing to dispatch, rewrite it after every ledger write, and publish it to the document destination after each write; in Pane it shows in the Session's Overview tab, and elsewhere you open the published URL beside the person at the first dispatch and refresh it in the same tab. Always end every progress message to the person with "Next: …". In Pane, 1 feature = 1 worktree = 1 branch = 1 Pane; reviews, audits, fixes and QA for it are tabs in that Pane, opened with `runpane panels create --pane <id>`, never a new Pane. Use `orchestrate-sessions`.
 
 For workspace ownership, session creation, associations, messaging, persistence, waiting and archiving, follow the host's injected instructions or the optional `host_policy` document. When the host owns those mechanics, use its tools rather than manual worktrees or processes; in Pane, that means `runpane`. Greenfield supplies the roles above them: phase approvals, review policy and completion requirements.
 
-Give each worker the canonical source, its completion criteria, and the document destination its repository names. Workers raise questions as numbered `needs_you` blocks. In Pane, a worker asks its blocking questions itself through Notify; once one is answered, number it, record the D-n and send `recorded:` to the asking tab only. Relay every other block as `orchestrate-sessions` says, labelled with its role and feature and with its files opened beside the person, record the answer as a D-n, and send it to the asking tab only.
+Give each worker the canonical source, its completion criteria, and the document destination its repository names. Workers raise questions as numbered `needs_you` blocks. In Pane, a worker asks its blocking questions itself through Notify; once one is answered, number it, record the D-n and send `recorded:` to the asking tab only. Relay every other block as `orchestrate-sessions` says, labelled with its role and feature and with its files opened beside the person, record the answer as a D-n, and send it to the asking tab only. Documents follow the document destination, not the host: when the workspace instructions name a file, artifact or bundle destination, publish there instead of keeping local files, even when the host says to keep documents local, and fall back to local files only when nothing else is available.
 
 - Launch `greenfield/planner` for plans. Under you, planners only plan.
 - After the user approves a plan, launch `greenfield/implementer` to build it. A clearly straightforward, authorized fix may go straight to the implementer as `no-plan` work.

plugins/greenfield/plugin.yaml

@@ -1,3 +1,3 @@
 name: greenfield
-version: 0.0.51
+version: 0.0.52
 cli_major: 0