@usenaive-sdk/cli 0.13.1 → 0.15.0

package/dist/commands/up.js

@@ -2,8 +2,9 @@ import { Command } from "commander";
 import { existsSync, readFileSync, readdirSync, statSync } from "node:fs";
 import { join, relative } from "node:path";
 import { pathToFileURL } from "node:url";
-import { agentOutput, agentError } from "../output.js";
+import { agentOutput, agentOutputExit, agentError } from "../output.js";
 import { apiRequest, handleApiError } from "../client.js";
+import { isConfigAuthoringError } from "../lib/config-errors.js";
 const WEB_IGNORE = new Set([
     "node_modules", ".next", ".git", ".vercel", ".ready", "dist", ".turbo", ".cache", "data", ".DS_Store",
 ]);
@@ -81,6 +82,15 @@ async function loadConfig(path) {
         return { ok: true, config: cfg };
     }
     catch (e) {
+        // Config authoring errors (e.g. system.root !== "ceo") must not look like a
+        // missing dependency — surface as invalid_input with the author's message.
+        if (isConfigAuthoringError(e)) {
+            return {
+                ok: false,
+                reason: "invalid",
+                message: e instanceof Error ? e.message : String(e),
+            };
+        }
         // The config itself threw. Almost always a NAMED define-time refusal, whose
         // message is written to be read by the person who wrote the config — so it
         // is surfaced verbatim rather than replaced with a guess.
@@ -161,6 +171,175 @@ export function brainReport(brains) {
         ...(brains.notes?.length ? { notes: brains.notes } : {}),
     };
 }
+/**
+ * How a loop's cadence PRINTS — the one place that decides, so the four lines
+ * below cannot disagree about it.
+ *
+ * An interval is spelled `every 3600s` rather than as a bare number: `(3600)`
+ * next to a name reads as an id, and the whole point of this line is that an
+ * operator can tell at a glance what is about to spend on a timer.
+ *
+ * The empty fallback is reachable only for an {@link AppliedLoop} carrying
+ * neither arm, which the fold refuses (`loop_cadence_invalid`) — so it exists to
+ * keep the report printable rather than to describe anything real.
+ */
+export function loopCadence(l) {
+    if (typeof l.everySeconds === "number")
+        return `every ${l.everySeconds}s`;
+    return l.cron ?? "no cadence";
+}
+/**
+ * Every loop this apply touched on a team, BOTH LANES FOLDED.
+ *
+ * A registered loop is real, recurring work the apply just scheduled, and
+ * reporting nothing about it made a firing schedule invisible — the reason this
+ * projection exists at all. It read `hermes?.agents` only, which was correct
+ * exactly as long as the durable lane registered nothing: a durable role's
+ * `loop` came back in `unconsumed` and there was no timer to print. Now that
+ * `registerDurableTeamLoops` (packages/api/src/services/system-staffing.ts)
+ * registers it against the runtime's own alarm, reading one lane would make a
+ * schedule the apply had just created invisible on the OTHER runtime — the same
+ * silence, moved.
+ *
+ * Folded rather than `durable ?? hermes` for the reason `agents` is: a MIXED
+ * team is reported by both materializers and preferring one drops the other's
+ * half.
+ */
+export function projectLoops(hermes, durable) {
+    return [...(hermes?.agents ?? []), ...(durable?.agents ?? [])]
+        .filter((a) => a.loop !== undefined)
+        .map((a) => ({ role: a.role, ...a.loop }));
+}
+/**
+ * One hint line per loop, plus one per loop this apply cancelled.
+ *
+ * 🔴 THE LIST COMMAND IS LANE-DEPENDENT AND NAMING THE WRONG ONE IS WORSE THAN
+ * NAMING NONE. `naive cron list` reads `cron_jobs`, which has no row for a
+ * durable tenant — an operator who followed it after a durable loop registered
+ * would find nothing and conclude the line above it had lied. A mixed team has
+ * both lanes at once, so the lookup is per ROLE and falls back to the team's.
+ */
+export function loopHints(t) {
+    const lines = (t.loops ?? []).map((l) => {
+        const lane = t.role_runtimes?.[l.role] ?? t.runtime;
+        const list = lane === "durable" ? `\`naive teams schedules ${t.name}\` shows it` : "`naive cron list` shows it";
+        const why = l.reason ? ` — ${l.reason}` : "";
+        const cadence = loopCadence(l);
+        return l.status === "registered"
+            ? `loop "${l.name}" (${cadence}) registered for ${t.name}/${l.role} — ${list}.${why}`
+            : l.status === "queued"
+                ? `loop "${l.name}" (${cadence}) for ${t.name}/${l.role} is QUEUED — nothing is firing on this cadence yet${why || " — the runtime could not take it yet; it lands when the runtime is reachable."}`
+                // THE UNSCHEDULABLE LINE NO LONGER ASSERTS *WHY*. It used to say the
+                // cadence "is not a cron expression the scheduler can compile", which
+                // was the only reason that existed when the only arm was cron. An
+                // interval loop on a hermes role is now also unschedulable, for a
+                // completely different reason, and that reason arrives in `reason`.
+                // Stating a cause the field no longer implies would make the report
+                // wrong exactly when it matters.
+                : `loop "${l.name}" (${cadence}) for ${t.name}/${l.role} is UNSCHEDULABLE — nothing was registered.${why || ` "${cadence}" is not a cadence this lane's scheduler can compile.`}`;
+    });
+    // A CANCELLED TIMER IS WORK THE APPLY DID. Printed for the same reason
+    // `archived` is: the config stopped declaring it, so something had to happen
+    // to it, and silence is the reading that leaves an operator unsure whether it
+    // is still spending.
+    return [
+        ...lines,
+        ...(t.loops_unscheduled ?? []).map((id) => `loop "${id}" UNSCHEDULED on ${t.name} — this config no longer declares it, so the runtime is no longer firing it.`),
+    ];
+}
+/**
+ * 🔴 WHAT THE CONTROL PLANE PUT IN THE DIGEST THAT THE CONFIG DID NOT.
+ *
+ * `projectTeamRecord` grants a durable team's LEAD the built-in `delegate` when
+ * the lane has more than one member. The grant is narrow and argued for at
+ * length where it is made, and it was reported NOWHERE: `naive up` prints the
+ * declared `can:`, and so do `/plan` and `/roster`, so the authority surface an
+ * operator reviews before running `naive teams apply … --expected-digest …`
+ * contained one capability more than anything on naive listed. A digest that
+ * moves for a reason no surface names is the same silence the manifest report
+ * itself exists to end, one field deeper.
+ *
+ * SAID PER TEAM AND ONLY WHEN THERE IS SOMETHING TO SAY. A one-member durable
+ * team gets no grant and no line.
+ */
+export function grantHints(t) {
+    if (!t.manifest_grants?.length)
+        return [];
+    return [
+        `team "${t.name}" manifest carries ${t.manifest_grants.length} capability the config did not declare: ` +
+            `${t.manifest_grants.join(", ")} — added by the control plane so the planner can hand sub-tasks to its ` +
+            `own members and wait for the result. It is IN the digest you review and bind, so it is named here ` +
+            `rather than left to be discovered in the record.`,
+    ];
+}
+/**
+ * One hint line per declared trigger, one per trigger this apply cancelled, and
+ * ONE RETAINED LINE for standing schedules this config did not author.
+ *
+ * A sibling of {@link loopHints} rather than a branch inside it, printed
+ * immediately after it, and the split is not cosmetic: a trigger has no ROLE.
+ * `agent({ loop })` reserves every firing to the member that declared it and
+ * every loop line says `team/role`; `team({ on })` fires UNRESERVED and the
+ * board hands the card to whoever is next. A line that named a role would name
+ * one that does not exist.
+ *
+ * 🔴 THE RETAINED LINE IS THE HALF THAT WOULD OTHERWISE BE INVISIBLE, and it is
+ * the reason this function exists at all. `registerTeamTriggers` refuses to
+ * cancel a schedule it cannot prove it wrote — the one destructive failure that
+ * cannot be undone by re-running anything — and then says nothing about it. A
+ * correct decision nobody is told about is the same defect one level up: the
+ * operator still has a timer spending on a cadence no config declares, and now
+ * also has no evidence it exists. The sentence is copied in shape from the
+ * brains one this file already prints, down to "remove one deliberately", so an
+ * operator meets one vocabulary for drift rather than two.
+ *
+ * 🔴 AND WHERE A FIRING WILL NOT SHOW UP, said once per team that declares any.
+ * A durable schedule's firing reaches NEITHER existing observability surface:
+ * `GET /v1/triggers/ledger` reads the `events` table, whose sources are
+ * `email|objective|cron|task|approval|company_channel` and which a durable alarm
+ * never writes, and `routeEvent` writes `trigger_deliveries` over a disjoint
+ * vocabulary it also never writes. The board is the only place the work appears.
+ * Naming that here is the cheap mitigation; reconciling the two ledgers is its
+ * own piece of work.
+ */
+export function triggerHints(t) {
+    const declared = t.triggers ?? [];
+    const lines = declared.map((tr) => {
+        const why = tr.reason ? ` — ${tr.reason}` : "";
+        switch (tr.status) {
+            case "registered":
+                return `trigger "${tr.key}" registered for ${t.name} as "${tr.name}" (${tr.cron}, UTC) — \`naive teams schedules ${t.name}\` shows it.${why}`;
+            case "blocked_unbound":
+                // NOT `queued`. The repair is a command a human runs, and the runtime
+                // will refuse every registration until they run it.
+                return `trigger "${tr.key}" (${tr.cron}, UTC) for ${t.name} is BLOCKED — the team's manifest is not bound, so the runtime refuses to schedule against it and NOTHING was registered${why || " — bind the manifest, then re-run `naive up`."}`;
+            case "queued":
+                return `trigger "${tr.key}" (${tr.cron}, UTC) for ${t.name} is QUEUED — nothing is firing on this cadence yet${why || " — the runtime could not take it yet; it lands when the runtime is reachable."}`;
+            default:
+                return `trigger "${tr.key}" for ${t.name} is UNSCHEDULABLE — nothing was registered.${why}`;
+        }
+    });
+    return [
+        ...lines,
+        ...(t.triggers_unscheduled ?? []).map((id) => `trigger "${id}" UNSCHEDULED on ${t.name} — this config no longer declares it, so the runtime is no longer firing it.`),
+        // The drift half. One line, all ids, mirroring the brains sentence verbatim
+        // in shape — including the fact that apply did NOT touch them.
+        ...(t.schedules_retained?.length
+            ? [
+                `schedules on ${t.name} RETAINED, not declared by this config: ${t.schedules_retained.join(", ")} — apply never cancels a schedule it cannot prove it wrote; remove one deliberately with \`naive teams unschedule ${t.name} <id>\`.`,
+            ]
+            : []),
+        ...(declared.length
+            ? [
+                // NAMED AS A ROUTE AND NOT AS A COMMAND, deliberately: there is no
+                // `naive triggers` verb on this build, and pointing an operator at a
+                // command that does not exist is the defect this line exists to
+                // avoid, not a smaller version of it.
+                `a declared trigger's firing appears on ${t.name}'s board and in NO trigger ledger — \`GET /v1/triggers/ledger\` reads the \`events\` table, which a durable alarm never writes to.`,
+            ]
+            : []),
+    ];
+}
 /**
  * The per-team accept-and-drop warning, one line per team that declared any.
  *
@@ -293,6 +472,189 @@ export function refusalNextStep(t) {
     }
     return null;
 }
+/**
+ * A team whose manifest is NOT bound, so its tick dispatches nothing.
+ *
+ * `refused` — the runtime (or the projection) refused the record itself.
+ * `delivered_not_applied` — the record stored, the bind was refused. The team
+ * is placed, addressable, and inert.
+ * `unreachable` — the runtime never answered, so nothing was delivered.
+ *
+ * `skipped` IS DELIBERATELY ABSENT, and that is the whole reason this is a
+ * named constant rather than an inline list. The API emits `skipped` only when
+ * placement already failed — there was nowhere to deliver to — and that team is
+ * ALREADY in `refusedTeams` and already printed with its placement refusal.
+ * Including it here would print one failure twice under two names and imply two
+ * things went wrong, which is the report lying in the generous direction.
+ *
+ * `applied` and `noop` are the bound states. `noop` in particular is a SUCCESS:
+ * the runtime already held that exact digest and rewrote nothing.
+ */
+const UNBOUND_MANIFEST_STATUSES = ["refused", "delivered_not_applied", "unreachable"];
+/**
+ * The `manifest` half of one team's report line, from the API's own team row.
+ *
+ * A SIBLING OF `placement`, NEVER NESTED INSIDE IT. The API's comment on the
+ * field this reads is explicit about why: "the tenant routes to the durable
+ * runtime" and "the runtime enforces what the config declared" are different
+ * facts, and a placed team with a refused manifest is exactly the state that
+ * must not read as success. Nesting one inside the other would collapse a
+ * distinction the API deliberately kept, and would make the refusal look like a
+ * detail of a successful placement.
+ *
+ * Absent when the API reported nothing — a hermes team has no manifest at all,
+ * and an older server does not send the field. An empty object rather than
+ * `{ manifest: undefined }`, so the printed envelope has no key for a fact
+ * nobody stated.
+ */
+export function projectManifest(durable) {
+    const m = durable?.manifest;
+    if (!m)
+        return {};
+    return {
+        manifest: {
+            status: m.status,
+            ...(m.digest ? { digest: m.digest } : {}),
+            ...(m.code ? { code: m.code } : {}),
+            ...(m.error ? { error: m.error } : {}),
+        },
+    };
+}
+/**
+ * WHAT `naive up` SAYS ABOUT MANIFEST DELIVERY, AND WHETHER IT MAY STILL EXIT 0.
+ *
+ * Extracted for the same reason `brainReport` is: the claim — "a refused
+ * manifest is reported in the runtime's own words and the apply exits
+ * non-zero" — is otherwise only assertable against a live API.
+ *
+ * Delivering the manifest is the step that turns a placed tenant into a working
+ * one. Before this existed the CLI decoded the placement and dropped the
+ * delivery, so a team that routed correctly and enforced NOTHING printed
+ * exactly like one that worked: `placement: { status: "placed" }`, `applied:
+ * true`, exit 0.
+ *
+ * 🔴 A `next_step` IS NOW OFFERED FOR `delivered_not_applied`, AND FOR NOTHING
+ * ELSE. This block previously offered none at all, under this reasoning:
+ *
+ *     The obvious candidate is `naive teams apply <team> --expected-digest
+ *     <digest>` and it is wrong TWICE on this build: `teamsCmd` registers no
+ *     `apply` subcommand, and the control plane routes `POST …/apply` through
+ *     `REFUSED_WRITES` to a 501.
+ *
+ * Both halves are now false, and the FIRST ONE WAS NEVER TRUE. `teams.ts`
+ * declares no subcommands at all — it walks `lib/teams-catalog.ts` — and that
+ * catalog has carried an `apply` row, with a REQUIRED `--expected-digest` that
+ * defaults to nothing, since before this branch was written. Verified by
+ * running the built CLI rather than by reading for it:
+ *
+ *     $ naive teams --help
+ *       apply [options] <team>   Record that an operator applied this exact
+ *                                manifest digest. Refuses a stale one
+ *
+ * The second half is false as of this change: `POST …/apply` is a
+ * `DURABLE_WRITES` row and reaches the runtime's own `apply` verb. So the
+ * command exists, the route exists, and the digest is already in hand — which
+ * is exactly the condition {@link refusalNextStep} sets for emitting one.
+ *
+ * `--tenant` IS SPELLED OUT, AND IT IS NOT OPTIONAL. `naive teams` requires it
+ * on every subcommand and has NO default, deliberately: "a command that guesses
+ * the tenant is a command that acts on the wrong tenant exactly once". A durable
+ * team's subject is its OWN — `ensureTeamSubject` mints one per declared team —
+ * so `--tenant @self` would address the operator's subject and bind a digest on
+ * a tenant that is not this team. The apply response carries the right id on
+ * `subject.tenant_user_id` and that is what is printed. If it is somehow absent
+ * the next_step is WITHHELD rather than emitted with a placeholder, because a
+ * command an operator has to guess a field in is the same dead end as a command
+ * that 501s.
+ *
+ * STILL NO next_step FOR `refused` OR `unreachable`, and the distinction is the
+ * point. `delivered_not_applied` means the record IS stored and only the bind
+ * failed — a retryable act with a known digest. `refused` means the runtime
+ * would not take the record at all, so there is nothing to apply and the fix is
+ * in the config; `unreachable` means nothing was attempted. Offering an apply
+ * for either would send an operator to run a command that cannot succeed.
+ */
+export function manifestReport(teams) {
+    const unbound = teams.filter((t) => t.manifest !== undefined && UNBOUND_MANIFEST_STATUSES.includes(t.manifest.status));
+    const hints = unbound.map((t) => {
+        const m = t.manifest;
+        // The refusing side's own sentence, verbatim. The runtime names the slug it
+        // could not resolve and lists what this deploy does ship; rewording that
+        // into "manifest delivery failed" throws away the only part an operator can
+        // act on.
+        const said = m.error ? `: ${m.error}` : "";
+        const code = m.code ? ` (${m.code})` : "";
+        return (`team "${t.name}" manifest ${m.status.toUpperCase()}${code}${said}` +
+            (m.status === "delivered_not_applied"
+                ? ` — the record IS stored at digest ${m.digest ?? "(none reported)"}; it is the BIND that was refused, ` +
+                    `so this team routes, accepts requests and dispatches nothing until that digest is applied.`
+                : m.status === "unreachable"
+                    ? ` — nothing was delivered, so the runtime is enforcing whatever it held before this apply.`
+                    : ` — nothing is bound, so this team's tick dispatches nothing.`));
+    });
+    const nextSteps = unbound.flatMap((t) => {
+        const m = t.manifest;
+        const tenantId = t.subject?.tenant_user_id;
+        // Every condition must hold: the record must be STORED (so there is
+        // something to bind), the digest must be KNOWN (the flag is required and
+        // has no default), and the team's own subject must be in hand.
+        if (m.status !== "delivered_not_applied" || !m.digest || !tenantId)
+            return [];
+        return [
+            {
+                command: `naive teams apply ${t.name} --tenant ${tenantId} --expected-digest ${m.digest}`,
+                description: `team "${t.name}": the record is stored and the BIND was refused, so this team routes and ` +
+                    `dispatches nothing. Review the authority surface that digest names, then bind it. The digest ` +
+                    `is passed explicitly because applying whatever is current is not a review — a stale one is refused.`,
+            },
+        ];
+    });
+    return { unbound, hints, nextSteps };
+}
+/**
+ * THE ONE PARAGRAPH SAID ABOUT UNBOUND MANIFESTS AS A GROUP, RATHER THAN PER
+ * TEAM — and it is emitted only for the teams {@link manifestReport} could NOT
+ * hand a repair command to.
+ *
+ * 🔴 IT USED TO CONTRADICT THE NEXT_STEP PRINTED THREE LINES ABOVE IT. Written
+ * inline in the command's action closure by parity 0, it read:
+ *
+ *     No `naive` command binds a manifest on this build: `naive teams`
+ *     registers no `apply` subcommand, and the control plane answers
+ *     `POST /v1/teams/.../apply` with 501.
+ *
+ * Both halves are false at HEAD and the first was never true — the full
+ * accounting is in {@link manifestReport}'s own comment, which emits
+ * `naive teams apply <team> --tenant … --expected-digest …` for
+ * `delivered_not_applied`. That is the SAME status that put a team in
+ * `unbound`, so an operator was handed a command and then told, one line later,
+ * that no such command exists. It survived because it was a string inside a
+ * 500-line closure that nothing imports and nothing could call.
+ *
+ * So it is a function now, for the reason `manifestReport` is one: a claim that
+ * cannot be called cannot be tested, and this one was wrong for two commits.
+ *
+ * WHAT IT SAYS NOW is the fact that is actually true of the teams it fires for:
+ * `naive teams apply` binds a digest the runtime has ALREADY STORED, so it can
+ * repair `delivered_not_applied` and nothing else. `refused` means the record
+ * was never taken; `unreachable` means it was never delivered. For both, the
+ * runtime's own sentence is printed above and re-running `naive up` re-delivers.
+ *
+ * The condition is "an unbound team that got no next_step", not "any unbound
+ * team": a team whose repair is printed does not need to be told there is none.
+ */
+export function unbindableNote(report) {
+    if (report.unbound.length <= report.nextSteps.length)
+        return [];
+    return [
+        "A manifest above is unbound with NO bind to offer. `naive teams apply <team> --tenant <id> " +
+            "--expected-digest <digest>` exists and works, but it binds a digest the runtime has already STORED — " +
+            "for `refused` nothing was stored, and for `unreachable` nothing was even delivered, so there is no " +
+            "digest to review. The refusing side's own sentence is printed above and names what it would not take. " +
+            "Re-running `naive up` re-delivers, which is the only self-serve path and only helps if the cause was " +
+            "transient.",
+    ];
+}
 /** Team names declared in the config, without evaluating anything the API will re-derive. */
 function declaredTeamNames(config) {
     const teams = config.teams;
@@ -405,13 +767,39 @@ export const upCmd = new Command("up")
         });
         return;
     }
-    // Fallback: the TOOLCHAIN is missing (or --local was asked for), so the config
-    // could not be evaluated at all — local, regex-only validation.
+    /* ── Fallback: the TOOLCHAIN is missing (or --local was asked for) ─────────
+     *
+     * The config could not be evaluated at all, so all that is left is local,
+     * regex-only validation. The PAYLOAD is deliberately unchanged — extracting
+     * what can be read and naming the install is genuinely the most useful thing
+     * to say, and the `unloadable` half of the union stays a soft outcome.
+     *
+     * 🔴 WHAT CHANGED IS THE EXIT CODE, AND ONLY WHEN THE USER DID NOT ASK FOR
+     * LOCAL-ONLY. `naive up` was asked to plan AND apply; on this branch it did
+     * neither, and it still exited 0. Measured on the published CLI (0.13.1), a
+     * config importing a package that does not resolve produced
+     * `success: true`, `applied: false`, exit 0 — so `naive up && echo deployed`
+     * printed "deployed" over a deployment that was never even planned. That is
+     * the defect docs/COVERAGE-TRUTH.md §5 recorded as "`naive up` exits 0 with
+     * `success:true` when it cannot evaluate the config"; the `invalid` half was
+     * closed above, this is the half that was left.
+     *
+     * Exit 3 is this CLI's OWN ladder for exactly this shape — see
+     * agentOutputExit in output.ts: "success, and the terminal state is not
+     * success", written because "a CI script reading 0 as 'the work is done'
+     * would otherwise count an `unverified` task as a pass". Nothing about the
+     * envelope's content moves, so an agent still gets the extraction and the
+     * install step; a shell script stops.
+     *
+     * `--local` keeps exit 0. There the user asked for local validation only and
+     * got precisely that — the terminal state IS the success.
+     */
     if (!load || !load.ok) {
         const source = readFileSync(found, "utf8");
         const projectMatch = /project\s*:\s*["'`]([^"'`]+)["'`]/.exec(source);
         const project = projectMatch?.[1] ?? "(unknown)";
-        agentOutput({
+        agentOutputExit({
+            exitCode: opts.local ? undefined : 3,
             action: "up",
             result: {
                 config: found,
@@ -431,6 +819,16 @@ export const upCmd = new Command("up")
                 opts.local
                     ? `Local validation only for "${project}".`
                     : `Validated ${found} locally, but could not evaluate it (install @usenaive-sdk/iac + jiti, or commit a naive.config.json).`,
+                // Said in the envelope as well as in the exit code, because an agent
+                // reads this and a shell script reads that, and neither should have to
+                // infer it from `applied: false`.
+                ...(opts.local
+                    ? []
+                    : [
+                        "NOTHING WAS PLANNED AND NOTHING WAS APPLIED — the config never evaluated, so no plan was " +
+                            "requested and no apply was sent. Exit code 3 (`success, and the terminal state is not " +
+                            "success`); do not read this as a completed deploy.",
+                    ]),
                 // Only ever printed for a real resolution failure now — an invalid config
                 // took the branch above. Said out loud so the two are never conflated again.
                 ...(load ? [`Module resolution failed: ${load.message}`] : []),
@@ -539,6 +937,7 @@ export const upCmd = new Command("up")
         const lanes = t.role_runtimes;
         const label = (role, status) => lanes?.[role] ? `${role} (${status}, ${lanes[role]})` : `${role} (${status})`;
         const agents = [...(hermes?.agents ?? []), ...(durable?.agents ?? [])].map((a) => label(a.role, a.provision_status));
+        const loops = projectLoops(hermes, durable);
         return {
             name: t.name,
             runtime: t.runtime,
@@ -546,6 +945,17 @@ export const upCmd = new Command("up")
             ...(lanes ? { role_runtimes: lanes } : {}),
             ...(durable?.subject ? { subject: durable.subject } : {}),
             agents,
+            ...(loops.length ? { loops } : {}),
+            ...(durable?.loops_unscheduled?.length ? { loops_unscheduled: durable.loops_unscheduled } : {}),
+            // The trigger half, carried WHOLE rather than counted. Each of these is
+            // a fact an operator may have to act on: a blocked trigger needs a
+            // manifest bound, a retained schedule needs a human decision, and a
+            // cancelled one is work this apply already did.
+            ...(durable?.triggers?.length ? { triggers: durable.triggers } : {}),
+            ...(durable?.triggers_unscheduled?.length ? { triggers_unscheduled: durable.triggers_unscheduled } : {}),
+            ...(durable?.schedules_retained?.length ? { schedules_retained: durable.schedules_retained } : {}),
+            // The authority the config did not declare — see {@link grantHints}.
+            ...(durable?.manifest_grants?.length ? { manifest_grants: durable.manifest_grants } : {}),
             archived: [...(hermes?.archived ?? []), ...(durable?.archived ?? [])],
             ...(durable?.placement
                 ? {
@@ -556,9 +966,13 @@ export const upCmd = new Command("up")
                     },
                 }
                 : {}),
+            // A SIBLING OF `placement`, NEVER NESTED INSIDE IT — see
+            // `projectManifest`, which is where the reason is written down.
+            ...projectManifest(durable),
         };
     });
     const refusedTeams = teams.filter((t) => t.placement?.status === "refused");
+    const manifests = manifestReport(teams);
     const brains = brainReport(data.brains);
     // Deploy cloud.web source to the provisioned web project(s) (Vercel builds + hosts).
     const webDeploys = {};
@@ -608,10 +1022,24 @@ export const upCmd = new Command("up")
         next_steps: [
             ...needsAction.map((r) => ({ command: `naive status`, description: `${r.name}: ${r.requirement ?? r.status}` })),
             ...refusedTeams.map(refusalNextStep).filter((s) => s !== null),
+            // The repair for a team that was placed and never bound. See
+            // `manifestReport` for why this is emitted only for
+            // `delivered_not_applied` and why `--tenant` is spelled out.
+            ...manifests.nextSteps,
             { command: `naive agent-profiles provision <name> --user <tenant>`, description: "Provision an agent profile for a tenant" },
         ],
         hints: [
             `Deployment "${project}" is ${deployment?.status ?? "?"}.`,
+            ...teams.flatMap(loopHints),
+            // IMMEDIATELY ALONGSIDE THE LOOP LINES, because they are the same kind
+            // of fact: a standing timer this apply either created, refused, or found
+            // and left alone. Separating them by half a screen would make "what
+            // recurs on this team after this apply" two reads instead of one.
+            ...teams.flatMap(triggerHints),
+            // BESIDE THE MANIFEST LINES, not the schedule ones: this is about the
+            // authority surface a digest carries, and the operator reading it is
+            // about to run `naive teams apply … --expected-digest …`.
+            ...teams.flatMap(grantHints),
             ...unconsumedWarnings(teamPlan),
             ...(legacyDeprecationNotice(config) ? [legacyDeprecationNotice(config)] : []),
             ...(agentsRenameNotice(config) ? [agentsRenameNotice(config)] : []),
@@ -645,6 +1073,12 @@ export const upCmd = new Command("up")
                 ? `team "${t.name}" PLACED on the durable runtime (${t.agents.length} agent(s)). Its jurisdiction is fixed permanently by the first control request.`
                 : `team "${t.name}" was already on the durable runtime (${t.agents.length} agent(s)); nothing was rewritten.`),
             ...refusedTeams.map((t) => `team "${t.name}" REFUSED (${t.placement?.code}): ${t.placement?.reason}`),
+            // Placement and delivery are reported separately because they fail
+            // separately: a PLACED team can still be inert. See `manifestReport`.
+            ...manifests.hints,
+            // Said once, not per team, exactly as the placement paragraph below is.
+            // See {@link unbindableNote} for what it now says and what it used to.
+            ...unbindableNote(manifests),
             // Said once, not per team. `naive runtime migrate` does not exist in this
             // CLI or any released one — see refusalNextStep — so a refusal with no
             // next_step gets the reason it has none instead of a command that 404s.
@@ -659,8 +1093,12 @@ export const upCmd = new Command("up")
         ],
     });
     // The apply did real work and said so; it must not ALSO report success for
-    // the teams it refused. Non-zero, so a CI pipeline stops here.
-    if (refusedTeams.length > 0)
+    // the teams it refused, NOR for the teams it placed and left inert. Both are
+    // "the apply ran and part of it did not take", which is exit 1 on this
+    // command's ladder — 3 is reserved for "the config could not be evaluated at
+    // all, so nothing was even planned", and here the infra, the pools and the
+    // hermes teams really were provisioned. Non-zero, so a CI pipeline stops.
+    if (refusedTeams.length > 0 || manifests.unbound.length > 0)
         process.exitCode = 1;
 });
 export const downCmd = new Command("down")