Let Codex chiefs publish command centers as private ChatGPT Sites

README.md

@@ -129,7 +129,8 @@ deleting `reference-transaction`.
 
 Read each skill before use. Delegation and review target T3 Code's orchestration
 MCP tools and its configured provider runtimes. Other workflows may need goal
-state tools, GitHub CLI, Claude artifact tools, optional Tailscale sharing, or
+state tools, GitHub CLI, Claude artifact tools or the Sites plugin for command
+center publication, optional Tailscale sharing, or
 Apple development tools. Linking skills does not install provider executables,
 authenticate accounts, or enable models.
 
@@ -276,8 +277,11 @@ the chief releases it, the chief lands only sets that span owners, and each
 Needs you first and Work second, rendered from the program record's last
 commit: each outcome with its finish line, results to open, layers, provisional
 state, and what each decision blocks. Answers go back through chat. Existing
-trackers stay authoritative. The page is a private Claude artifact, so the chief
-runs in Claude and republishes it after each commit that changes it. On reload,
+trackers stay authoritative. Claude chiefs publish a private Claude artifact;
+Codex chiefs publish a private ChatGPT Site when the Sites plugin is available.
+The chief reuses its backend target and republishes after each commit that
+changes the page, and on resume or chief move. A backend change updates the
+current page link after successful publication. On reload,
 the page restores your tab, open sections, selected decision, and scroll
 position; local browser tests cover this. In Claude's web viewer, an open page
 moved to a newly published version without a reload, kept its selected tab, and

SOURCES.md

@@ -468,8 +468,17 @@ board of stage lanes. It replaces the supplied archive's artifact database and
 integrations; no archive code or prose is copied. Validation rejects
 provisional landings, PRs on a Try, stacks on another owner's unmerged layer
 without a provisional mark, terminal rows with active blockers, entries that
-name missing work, and fields the schema doesn't name. The command center is a private Claude artifact per program,
-so only a Claude session can be chief. `render_dashboard.py --page` renders the
+name missing work, and fields the schema doesn't name. Claude chiefs publish a
+private Claude artifact; Codex chiefs use the available
+plugin-managed `sites:sites` skill for a private ChatGPT Site with the existing
+HTML as buildless `dist/index.html`. Chiefs need their backend's tools. Each
+backend reuses its target; Site identity persists in `.openai/hosting.json`.
+`hosting` holds the current successful publication's URL, with no extra
+provider-switch approval or parallel program record. Existing chief ownership
+and takeover coordination remain. Hosting-link commits render normally without
+redeploying an unchanged page. The published-page marker advances only after
+confirmed publication, including a successful terminal Sites deployment;
+failures remain visible. `render_dashboard.py --page` renders the
 last commit beside the last published page, says whether it changed, and stamps
 the commit time that changed it; the chief republishes on a change and on every
 resume and chief move. The page keeps the viewer's place in session storage;

skills/chief-of-staff/SKILL.md

@@ -25,8 +25,10 @@ comparison through [Swarm](../swarm/SKILL.md) or [Arena](../arena/SKILL.md).
 The user can enter an owner's session directly; reconcile their new direction
 before you dispatch work that depends on it.
 
-Only a Claude session with the artifact tools can be chief, since the chief
-publishes the command center; elsewhere, ask the user to start the chief in one.
+The chief must have its session's [publishing tools](references/hosting.md):
+Claude artifact tools for Claude, or the available Sites plugin for Codex.
+If those tools are unavailable, report the blocker and ask the user to use a
+session with them; do not install plugins automatically.
 Only the record's current chief acts on program items and writes the record.
 Check it before acting on a request, direction, report, event, or pasted answer;
 a thread that is not the chief forwards the item under

skills/chief-of-staff/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Chief of Staff"
-  short_description: "Carry several outcomes through Implement owners; the chief runs in Claude"
+  short_description: "Carry several outcomes through Implement owners"
   default_prompt: "Use $chief-of-staff to carry these outcomes to their finish lines through Implement owners."

skills/chief-of-staff/references/chief-move.md

@@ -34,9 +34,9 @@ fails another way, stop and tell the user the takeover is incomplete.
 
 ## After either
 
-The new chief takes over the program folder as it stands. The move or takeover
-completes when it can read the artifact in `hosting`. If it can't, it asks the
-user to approve a new artifact, creates it, records the new link, and gives it to
-the user. It then [publishes the page](hosting.md), reconciles state as on
-resume, sends owners their route, watches any delegated owner's pending PRs, and
-asks any remaining old thread to unwatch.
+The new chief takes over the program folder as it stands, keeping its single
+record and git history. It [publishes the page](hosting.md) with its session's
+backend, reusing that backend's target or recording the new URL after success.
+The move or takeover completes after successful publication and any link write.
+It reconciles state as on resume, sends owners their route, watches any
+delegated owner's pending PRs, and asks any remaining old thread to unwatch.

skills/chief-of-staff/references/hosting.md

@@ -1,7 +1,13 @@
 # Publish the command center
 
-The command center is one private Claude artifact per program, and `hosting`
-holds its link.
+Publish one private command center per program. Claude sessions use a private
+Claude artifact; Codex sessions use a private ChatGPT Site through the available
+Sites plugin. The chief must have the selected publishing tools. If they are
+unavailable, stop and report the blocker; do not install plugins automatically.
+`hosting` holds the current published page's URL. Keep one canonical
+`program.json` and git history, without a parallel backend mirror.
+
+## Render and publish
 
 After each commit under [write the record](program-state.md#write-the-record),
 render `HEAD` from this skill's folder:
@@ -11,15 +17,44 @@ python3 scripts/render_dashboard.py --state /absolute/path/program.json --page /
 ```
 
 It writes `command-center.next.html` beside the page file and prints `changed`
-when that differs from `command-center.html`, the last page you published. On
-`changed`, publish the `.next` file to the artifact in `hosting`, then move it
-over the page file:
+when that differs from `command-center.html`, the last successfully published
+page. On `changed`, publish the `.next` file. On every resume and chief move,
+force publication even when unchanged, using the page file in that case, so
+skill updates reach it.
+
+Reuse the selected backend's existing target on successive updates. If
+`hosting` is absent or points to the other backend, create or use the selected
+target and publish there. Changing backend needs no extra provider-switch
+approval; [chief ownership](chief-move.md) still needs its existing coordination
+and takeover authorization.
+
+- **Claude:** update the private artifact in `hosting`. Create one when there is
+  no artifact target. Confirm the artifact update succeeded.
+- **Codex:** discover and read the plugin-managed `sites:sites` skill. Give it
+  the generated HTML as a buildless static Site at `dist/index.html`. Keep a
+  durable Site source checkout with its tracked `.openai/hosting.json`; preserve
+  its `project_id` and reuse that Site. Let Sites own registration, source sync,
+  packaging, and private publication. Its source repository is deployment source,
+  not another program record. Use no framework starter, package install, local
+  server, new scheduler, or public audience. Wait for a successful terminal
+  deployment result with its URL; registration or a saved version alone is not
+  publication.
+
+Only after successful publication, move a published `.next` file over the page
+file:
 
 ```bash
 mv /absolute/path/command-center.next.html /absolute/path/command-center.html
 ```
 
-A failed or skipped publish leaves the page file as it was, so the next render
-still prints `changed`. Create the artifact only when `hosting` has none, then
-record its link. On every resume and chief move, publish the page file even when
-unchanged, so skill updates reach it.
+If the published URL differs from `hosting`, record it through the normal
+checked record write and give the user the new URL. Render that metadata commit
+as usual: the renderer omits `hosting`, so an otherwise unchanged page needs no
+second deployment. This completes the link write without a recursive publish;
+if the render does change, publish it normally.
+
+A failed or skipped publication leaves the last successfully published page
+file and `hosting` as they were. Stop and report the failure and any created
+target or saved version needed to retry. If recording the link fails after
+publication, report the deployed URL and the incomplete record write. Keep Site
+identity so a retry uses the same target.

skills/chief-of-staff/references/program-state.md

@@ -59,7 +59,9 @@ you reply or move on:
 6. [Publish the command center](hosting.md), except after a
    [chief move](chief-move.md), where the new chief publishes.
 
-A write is done when its commit lands and its page is published. On a git or
+A write is done when its commit lands and its page is published or the render
+confirms the published page is unchanged. Hosting-link commits follow
+[publication bookkeeping](hosting.md#render-and-publish). On a git or
 publish error, stop and report it to the user.
 
 ### File format
@@ -78,7 +80,7 @@ type Program = {
   finishLine?: string; // a program-wide note, such as who decides merges
   demo?: boolean; // true only for an illustrative example
   chief: string; // the current chief thread
-  hosting?: string; // the command center artifact's link
+  hosting?: string; // the current published command center's URL
   next: string; // the next useful action
   request: { text: string; sources?: string[] }; // the original request and its message sources
   corrections?: Entry[]; // accepted corrections