`gtmesh status`

Prints the state of the mesh: per-status counts, drift, the writer’s worklist, and (with --env) the renderable set for an environment.


gtmesh status [--env <env>] [--summary]

What it does

gtmesh status is the read-only dashboard for your registry. In one command it shows:

Per-status counts — how many pages sit in each lifecycle state (planned/backlog, queued, writing, review, published, needs_update).
Drift — built pages whose inputs have moved since seal stamped them, in the two shapes that have different fixes (see below).
The writer worklist — the pages currently in writing that need a body.
The render set — with --env, the slugs that would render for that environment (the same set render-manifest emits).

Pass --summary for counts only, when you don’t want the writing worklist.

It changes nothing — run it as often as you like.

Arguments & flags

Option	Description	Default
`--env <env>`	Also show the renderable set for this environment (e.g. `local`, `dev`, `prod`)	none
`--summary`	Counts only — omit the writing worklist	off

The global options (--project, --json, --quiet) also apply.

Reads & writes

Consumes: the committed registry (and, with --env, your environment’s render rules).
Produces: a report to your terminal. Read-only.
Commits: nothing.

Examples


gtmesh status                 # counts, drift, and the writer worklist
gtmesh status --summary       # just the counts
gtmesh status --env prod      # also show what would render in prod
gtmesh status --json          # machine-readable, for a script or CI

The drift line

When a built page has fallen behind the graph, status prints one line:


drift — content: 4, schema: 2 (`gtmesh doctor` names the fix)

Two counts, because they have two different remedies:

Count	What moved	The fix
`content`	the page’s assignment (`brief_hash`) — new demand, a changed entity fact, so the prose may answer an older brief	if the body still answers it, re-stamp: `gtmesh page amend <slug…>` → `seal` → `publish`. If the assignment genuinely moved, re-author it: `gtmesh page recreate <slug…>` → the writer → `seal` → `publish`. A published page keeps serving its old body until the revision ships
`schema`	the page type’s shape (`current_schema_hash`) — you edited `schemas/<type>.schema.yaml` or the shared base	`gtmesh apply`: it re-validates each body, restamps the ones that still fit, and moves the rest to `needs_update` for the writer

Drift is measured on built pages only — a page that was never sealed (or one you re-opened with page recreate) is governed by its status, not by a hash. gtmesh doctor’s built-drift check names the pages behind each count. gtmesh plan proposes the derived ones as rewrite (spec-change) / rewrite (schema-change); a page you authored is pinned by reconcile, so it stays in this count until you clear it yourself.

The render projection is not drift: mesh links re-resolve into site.manifest.json on every build, so a projection change is a manifest diff, not a page action.

The engine-files footer

When the engine has bundled files your mesh hasn’t taken yet, status closes with one line: “2 engine file(s) pending — gtmesh upgrade takes them (gtmesh doctor lists which)”. It appears only for files a plain gtmesh upgrade applies in place; a file you edited is never repeated here (it would nag forever until you merged it) — that one lives in doctor. Nothing pending, nothing printed.

render-manifest — emit the renderable slug set to a file.
Lifecycle & reconcile — the statuses and drift this report reflects.
Reference — the version-exact flag list.

gtmesh status