diff --git a/‎.changeset/21323-verify-author-time-rules.md‎
Lines changed: 22 additions & 0 deletions b/‎.changeset/21323-verify-author-time-rules.md‎
Lines changed: 22 additions & 0 deletions
diff --git a/‎content/docs/deployment/cli.mdx‎
Lines changed: 57 additions & 0 deletions b/‎content/docs/deployment/cli.mdx‎
Lines changed: 57 additions & 0 deletions
diff --git a/‎packages/cli/src/commands/verify.ts‎
Lines changed: 97 additions & 6 deletions b/‎packages/cli/src/commands/verify.ts‎
Lines changed: 97 additions & 6 deletions
@@ -0,0 +1,22 @@
+---
+'@objectstack/cli': minor
+---
+
+fix(cli)!: `os verify` runs the author-time rules first, and a stack they refuse fails `verify` with the findings `os validate` reports (#21323)
+
+Clause-②: yes (narrowing)
+
+<!-- adr-0087: not-required (no-migration-prescription) a CLI command's verdict, not a declaration: os verify now refuses, before it boots anything, a stack the author-time rule registry refuses or that does not parse against the protocol schema. No authorable key, spelling, export or stored shape moves: every stack parses and loads exactly as before, os validate and os build answer exactly as before, and nothing on the metadata load path is read or rewritten. What an author does about a refusal is fix the finding the message names, which os validate and os build already report for the same stack, so there is no rewrite a ledger entry could carry. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id covers a command's verdict (not registered / already-registered); and the change is CLI behaviour, not a TypeScript declaration (not runtime-interface-only / type-surface-only). -->
+
+**BREAKING** — `os verify` narrows what it passes. It ships as `minor` under the launch-window convention for accept-set narrowings.
+
+**What was accepted before.** `os verify` booted the app and exercised CRUD round-trip fidelity and, with `--rls`, the RLS invariant — and nothing else. A stack carrying a lookup to an object that does not exist, an action `visible` expression naming a field without `record.`, or a list column naming no field booted, round-tripped its records and printed `✓ verify passed` at exit 0, while `os validate`, `os build` and `os lint` all refused it. The documented done-bar ("`objectstack verify` is green") was green on a stack the build refuses to ship.
+
+**What is refused now.** `os verify` runs two stages. The first is the author-time rule registry `os validate` runs, over the stack prepared the way `os validate` prepares it: normalized, inline handlers lowered, parsed against the protocol schema, the SDUI manifest read beside the config, judged whole and then once per package of a multi-package artifact. A gating finding, or a stack that does not parse, exits 1 with those findings and the runtime stage never starts:
+
+- text face: `✗ Author-time rules failed (N issues) — the runtime stage did not run`, then each finding with its rule and location (the per-package and schema refusals have their own sentence);
+- `--json`: the command's failure envelope, `error` (the sentence), plus a new key, `errors`, carrying the findings in the shape `os validate --json` carries them under `errors` — rule findings (with `package` on a per-package one), or the schema issues.
+
+Advisories never fail the stage; the text face counts them and points at `os validate`. On a passing stack the text face prints one step line and `✓ Author-time rules passed (N rules)` before the runtime stage, and the `--json` report of a run that reaches the runtime stage is unchanged.
+
+**Who is affected.** Only a stack `os build` already refuses: the first stage runs the same gating rules over the same prepared stack, so every stack it refuses, `os build` refuses too. The remedy is the one `os validate` prints for each finding. Measured with this branch's CLI over the examples at `222ecc27f9` (unchanged on this branch): `os validate` exits 0 on `examples/app-todo`, `examples/app-crm`, `examples/app-showcase` and `examples/app-multi-package`, so none of the four is refused by the new stage.
@@ -1614,6 +1614,7 @@ emits a scoped, publishable `@objectstack/plugin-<name>`, and it lands under
 | Command | Description |
 |---------|-------------|
 | `os lint [config]` | Every author-time gate `validate`/`build` run, plus style and convention checks |
+| `os verify` | The author-time rules `validate` runs, then boot the app in-process and verify it through the real HTTP stack |
 | `os test [files]` | Run Quality Protocol test scenarios against a running server |
 | `os doctor` | Check development environment health |
 
@@ -1679,6 +1680,62 @@ the flag was in effect), `failing` (the count the exit code was read from —
 `errors`, or `errors + warnings` under `--strict`) and `passed` (`failing` is
 `0` — the same statement the exit code makes).
 
+#### `os verify`
+
+The done-bar: `os verify` green means the author-time rules pass **and** the
+app behaves at runtime. It runs two stages, in order, and the second starts
+only when the first passes.
+
+```bash
+os verify                                      # Author-time rules, then CRUD round-trip fidelity
+os verify --app ./objectstack.config.ts --rls  # Also prove the cross-owner RLS invariant
+os verify --rls --multi-tenant --json          # Org-scoped boot, structured report
+```
+
+1. **Author-time rules.** The rule registry `os validate` runs, over the stack
+   prepared the way `os validate` prepares it: normalized, inline handlers
+   lowered, parsed against the protocol schema, and judged whole and then once
+   per package of a multi-package artifact. A stack that does not parse, or
+   that any gating rule refuses, fails the run here with those findings — the
+   same ones `os validate` reports — and the app is never booted. Advisories
+   (`warning` and `info` findings) never fail `os verify`; the text face counts
+   them, and `os validate` prints them. This stage is the rule registry, not all
+   of `os validate`: the package-docs lint, the capability-provider check, the
+   picklist-reference and view-container-name checks and `--strict` stay
+   `os validate`'s, so run it too.
+2. **Runtime.** Boot the app in-process and exercise it through the real HTTP
+   stack: for each object, a record derived from its fields is created, read
+   back and compared (CRUD round-trip fidelity), and a create, read or
+   fidelity failure fails the run. With `--rls`, a second fresh boot proves the
+   cross-owner invariant — a member must not write what it cannot read — for a
+   probe persona and for one persona per declared position, and a hole fails
+   the run. `--multi-tenant` boots org-scoped so tenant-isolation RLS policies
+   apply; a walled tenancy posture (`OS_TENANCY_POSTURE` set to `isolated` or
+   `group`) asks for the same boot.
+
+The config is the one `--app` names, or the auto-detected one — see
+[Config File Auto-Detection](#config-file-auto-detection).
+
+**Exit status.**
+
+| Exit | Meaning |
+|---|---|
+| `0` | Both stages passed: no gating author-time finding, and no runtime failure |
+| `1` | The author-time stage refused the stack (the runtime stage did not run), the runtime stage found failures, or the command could not run at all (no config found, a config that does not load, a boot failure) |
+
+**`--json`.** What the document carries depends on where the run ended:
+
+- **Refused by the author-time stage:** `{ "error": "<sentence>", "errors": [...] }`,
+  where `errors` carries the findings in the shape `os validate --json` carries
+  them under `errors` — the gating findings (`severity`, `rule`, `where`,
+  `path`, `message`, `hint`, plus `package` for a finding raised inside one
+  package of the artifact), or the schema issues when the stack does not parse.
+- **Reached the runtime stage:** the report — `app`, `config`, `multiTenant`,
+  `crud`, `rls` (with `--rls`) and `hardFailures`, the count the exit status is
+  read from.
+- **Could not run:** `{ "error": "<sentence>" }`, plus `code` and `httpStatus`
+  when the failure carries them.
+
 #### `os test`
 
 Runs Quality Protocol test scenarios (JSON-based BDD) against a running ObjectStack server.
 
@@ -1,6 +1,7 @@
 // Copyright (c) 2026 ObjectStack. Licensed under the Apache-2.0 license.
 
 import { Command, Flags } from '@oclif/core';
+import { dirname } from 'node:path';
 import chalk from 'chalk';
 import { resolveTenancyPosture } from '@objectstack/types';
 import { postureEnforcesWall } from '@objectstack/spec/security';
@@ -19,9 +20,16 @@ import {
   type RlsProbeDescriptor,
   type RlsPositionPersonaInput,
 } from '@objectstack/verify';
+import { authoringRulesFor } from '@objectstack/lint';
 import { loadConfig } from '../utils/config.js';
+import { judgeAuthorTimeRules, VERIFY_RULE_COMMAND } from '../utils/author-time-rules.js';
 import {
   printError,
+  printStep,
+  printSuccess,
+  printAuthoringRuleErrors,
+  formatZodErrors,
+  JSON_FULL_LIST_REMEDY,
   emitJson,
   isExitSignal,
   errorCodeFields,
@@ -60,16 +68,22 @@ export function resolveVerifyMultiTenant(flags: { 'multi-tenant'?: boolean }): b
 }
 
 /**
- * `objectstack verify` — boot the app in-process and exercise it through the
- * real HTTP stack, asserting runtime behavior the static gates can't see:
- *   - data fidelity: author → write → read → assert, per object/field type
- *   - authorization (--rls): "you can't write what you can't read" (#1994 class)
+ * `objectstack verify` — two stages, in order:
  *
- * Exits non-zero on real failures so it drops straight into CI.
+ *   1. the author-time rules — the registry `os validate` runs, over the stack
+ *      prepared the way `os validate` prepares it (`utils/author-time-rules.ts`).
+ *      A gating finding fails the run with those findings, and stage 2 never
+ *      starts (#21323);
+ *   2. boot the app in-process and exercise it through the real HTTP stack,
+ *      asserting runtime behavior the static gates can't see:
+ *        - data fidelity: author → write → read → assert, per object/field type
+ *        - authorization (--rls): "you can't write what you can't read" (#1994 class)
+ *
+ * Exits non-zero on either stage's failures so it drops straight into CI.
  */
 export default class Verify extends Command {
   static override description =
-    'Boot the app in-process and verify it through the real HTTP stack (CRUD round-trip fidelity + the cross-owner RLS invariant)';
+    'Run the author-time rules os validate runs, then boot the app in-process and verify it through the real HTTP stack (CRUD round-trip fidelity + the cross-owner RLS invariant)';
 
   static override examples = [
     '<%= config.bin %> verify',
@@ -148,6 +162,10 @@ export default class Verify extends Command {
   }): Promise<void> {
     const { config, absolutePath } = await loadConfig(flags.app);
 
+    // Stage 1 — the author-time rules, before anything boots. A failure here
+    // exits inside the call; see `runAuthorTimeStage`.
+    await this.runAuthorTimeStage(config as Record<string, unknown>, absolutePath, flags.json);
+
     const multiTenant = resolveVerifyMultiTenant(flags);
 
     // Data fidelity runs on its own pristine stack.
@@ -263,4 +281,77 @@ export default class Verify extends Command {
     // stop(), so a bare return would hang. exit() also encodes the CI contract.
     this.exit(hardFailures > 0 ? 1 : 0);
   }
+
+  /**
+   * Stage 1 — the author-time rule registry `os validate` runs, over the stack
+   * prepared the way `os validate` prepares it (#21323).
+   *
+   * `os verify` used to start at the boot. A stack `os validate`, `os build`
+   * and `os lint` all refuse — a lookup to an object that does not exist, an
+   * action `visible` naming a field without `record.`, a list column naming no
+   * field — booted, round-tripped its records and printed `✓ verify passed`:
+   * none of the three is a runtime FAILURE, each is metadata the runtime
+   * silently does nothing with. That made the documented done-bar a false
+   * green. So the rules run first, and a gating finding stops the run before
+   * the runtime stage starts — "verify is green" now implies the rule stage of
+   * `os validate` is green.
+   *
+   * Exits 1 on a refusal (`this.exit` throws, so the call never returns then).
+   * The `--json` face keeps this command's failure envelope — `error`, the
+   * sentence — and adds `errors`, carrying the findings in the shape
+   * `os validate --json` carries them under the same key: rule findings on a
+   * rule refusal (each per-package one with its `package`), Zod issues on a
+   * schema refusal. Advisories never fail the stage; the text face counts them
+   * and points at `os validate`, which prints them.
+   */
+  private async runAuthorTimeStage(
+    config: Record<string, unknown>,
+    absolutePath: string,
+    json: boolean,
+  ): Promise<void> {
+    const ruleCount = authoringRulesFor(VERIFY_RULE_COMMAND).length;
+    if (!json) printStep(`Running author-time rules (${ruleCount})...`);
+    const { refusal, advisories } = judgeAuthorTimeRules(VERIFY_RULE_COMMAND, config, dirname(absolutePath));
+
+    if (refusal === null) {
+      if (!json) {
+        printSuccess(`Author-time rules passed (${ruleCount} rules)`);
+        if (advisories.length > 0) {
+          this.log(chalk.dim(`    ${advisories.length} advisory finding(s) — \`os validate\` prints them`));
+        }
+        this.log('');
+      }
+      return;
+    }
+
+    const STAGE_2_SKIPPED = 'the runtime stage did not run';
+    let sentence: string;
+    let errors: unknown[];
+    if (refusal.stage === 'schema') {
+      errors = refusal.error.issues;
+      sentence = `Validation failed (${errors.length} issue${errors.length > 1 ? 's' : ''}) — ${STAGE_2_SKIPPED}`;
+    } else {
+      errors = refusal.errors;
+      const n = `${errors.length} issue${errors.length > 1 ? 's' : ''}`;
+      sentence =
+        refusal.stage === 'rules'
+          ? `Author-time rules failed (${n}) — ${STAGE_2_SKIPPED}`
+          : `Author-time rules failed inside the artifact's packages (${n}) — ${STAGE_2_SKIPPED}`;
+    }
+
+    if (json) {
+      await emitJson({ error: sentence, errors }, 0, { compact: true });
+      this.exit(1);
+    }
+    this.log('');
+    printError(sentence);
+    if (refusal.stage === 'schema') {
+      formatZodErrors(refusal.error);
+    } else {
+      // `--json` on this same exit publishes every one of them as `errors`, so
+      // the pointer resolves to the complete list.
+      printAuthoringRuleErrors(refusal.errors, { remedy: JSON_FULL_LIST_REMEDY });
+    }
+    this.exit(1);
+  }
 }