{"id":"ops/review-goals","relativePath":"ops/review-goals.md","title":"Review Goals Audit","markdown":"# Review Goals Audit\n\n`pnpm review:goals` is the 10/10 review-goal audit. It collects the local gates\nthat came out of the project review and separates them from evidence that cannot\nbe fabricated locally.\n\nRun it locally:\n\n```bash\npnpm review:goals\npnpm review:goals:local\npnpm review:goals:check\n```\n\nUse `pnpm review:goals:local` in CI when the expected state is \"all local gates\nare complete, but real-world evidence is still pending.\" It exits non-zero only\nwhen `score.incomplete > 0`, and version-5+ artifacts expose the same result as\ntop-level `localGateStatus: \"passed\" | \"failed\"`. Use `pnpm review:goals:check`\nfor the final strict 10/10 gate; version-20+ artifacts expose that result as\ntop-level `strictGateStatus: \"passed\" | \"failed\"`, and it must keep failing\nuntil production, partner, and customer evidence is actually present.\n\nThe command writes timestamped JSON and Markdown evidence to\n`artifacts/review-goals/`, including `review-goals-latest.json` and\n`review-goals-latest.md`. JSON artifact `version: 45` adds top-level\n`readinessClaim`, a machine-readable boundary that names the allowed local-gate\nclaim, the blocked strict-production claim, and the production proof scopes\nstill needed before anyone can call the project strict 10/10 ready. Version 44 adds\n`blockedByExternalEvidenceGoals[].actionBreakdown[].blockerCount`,\n`artifactCount`, and `requirementCount`, so each blocked-goal action exposes\ndashboard-ready totals without counting its blocker, artifact, or requirement\narrays. Version 42 adds\n`blockedByExternalEvidenceGoals[].scopeBreakdown[].nextActionIds`, so each\nnamed blocked goal can join scoped handoffs to grouped `nextActions` rows\nwithout interpreting legacy `actionIds`. Version 41 adds\n`blockedByExternalEvidenceGoals[].scopeCount`, so each named blocked goal shows\nwhether its remaining work spans one or multiple execution lanes without\ncounting `executionScopes[]`. Version 40 adds\n`blockedByExternalEvidenceGoals[].actionCount`, `commandCount`, and\n`artifactCount`, so each named blocked goal exposes dashboard-ready handoff\ntotals without counting arrays. Version 39 adds\n`blockedByExternalEvidenceGoals[].nextEvidenceRequirements` and\n`requirementCount`, so each blocked-goal handoff carries its exact acceptance\ncriteria directly. Version 38 adds\n`externalEvidenceBlockerSummary[].nextActionIds` and scoped `actionCount`, so\neach blocker-scope summary points directly at the grouped remediation actions.\nVersion 37 adds\n`externalEvidenceBlockerSummary[].nextEvidenceRequirements` and scoped\n`requirementCount`, so each blocker-scope summary carries its acceptance\ncriteria directly. Version 36 adds `nextActionSummary[].actionCount`, so each\nexecution-scope lane exposes its action total directly while legacy `count`\nremains for compatibility. Version 35 adds top-level\n`strictGateHandoff.nextActionCount` and scoped\n`strictGateHandoff.scopeBreakdown[].nextActionCount`, so strict handoff\ndashboards can display executable action totals without counting action ID\narrays. Version 34 adds scoped\n`blockedByExternalEvidenceGoals[].scopeBreakdown[].remediationCommands`,\n`artifactTargets`, and `nextEvidenceRequirements`, so per-goal blocked\nhandoffs carry the executable operator payload without joining back through\n`actionBreakdown`. Version 33 adds\n`blockedByExternalEvidenceGoals[].scopeBreakdown[].actionCount`,\n`commandCount`, `artifactCount`, and `requirementCount`, so per-goal blocked\nhandoffs can display scoped action, command, artifact, and acceptance-criteria\ntotals without counting nested arrays. Version 32 adds\n`strictGateHandoff.requirementCount` and scoped\n`strictGateHandoff.scopeBreakdown[].requirementCount`, so dashboards can display\ndistinct next-evidence acceptance criteria without counting long requirement\narrays; these counts are deduplicated and can be lower than blocker counts.\nVersion 31 adds `strictGateHandoff.artifactCount` and scoped\n`strictGateHandoff.scopeBreakdown[].artifactCount`, so dashboards can display\ndistinct evidence-artifact target totals without counting arrays. Version 30\nadds `strictGateHandoff.commandCount` and scoped\n`strictGateHandoff.scopeBreakdown[].commandCount`, so dashboards can display\ndistinct remediation-command totals without counting arrays; scoped action\ncounts remain separate because one command can appear in more than one\nexecution scope. Version 29 adds `strictGateHandoff.goalCount` and scoped\n`strictGateHandoff.scopeBreakdown[].goalCount`, so the strict-gate operator\npayload exposes affected-goal totals without consumers counting arrays. Version\n28 adds\n`strictGateHandoff.nextActionIds[]` and scoped\n`strictGateHandoff.scopeBreakdown[].nextActionIds[]`, so the strict-gate\noperator payload points directly at the executable `nextActions[]` rows without\nreconstructing command/scope keys. Version 27 adds\n`strictGateHandoff.blockerIds[]` and scoped\n`strictGateHandoff.scopeBreakdown[].blockerIds[]`, so the strict-gate operator\npayload names the exact failing checks without requiring consumers to join\nthrough goal rows or blocker summaries. Version 26 adds\n`strictGateHandoff.scopeBreakdown[]`, so the strict-gate operator payload keeps\ndeployment-environment and real-world-evidence commands, artifacts, blockers,\ngoals, and evidence requirements separated without another join. Version 25 adds\n`strictGateHandoff.nextEvidenceRequirements[]`, so the consolidated strict-gate\noperator payload includes the exact evidence sentences from the scoped action\nrows, not only commands and artifact paths. Version 24 adds top-level\n`strictGateHandoff`, a machine-readable strict-gate operator handoff that\nconsolidates failing summary IDs, execution scopes, blocker count, affected\ngoals, remediation commands, and artifact targets without requiring consumers\nto re-join the summary rows. Version 23 extends the runtime invariant guard so\nevery `strictGateFailureSummary[]` field must match the derived strict-gate\nrows, not just the row IDs. Version 22 adds top-level\n`strictGateFailureSummary[]`, a structured dashboard-ready form of strict gate\nfailure rows with kind, scope, blocker counts, goals, commands, artifacts, and\nthe matching human reason. Version 21 adds top-level\n`strictGateFailureReasons[]`, so a failed strict 10/10 gate names the local,\ndeployment-environment, and real-world evidence lanes that still block launch\nreadiness instead of forcing dashboards to reconstruct those sentences. Version\n20 adds top-level `strictGateStatus`, the machine-readable result for\n`pnpm review:goals:check`, so CI, dashboards, and launch handoffs do not have\nto infer strict 10/10 readiness from the broader status string. Version 19 keys\n`nextActions` by\nremediation command plus `executionScope`, so a command that appears in both\ndeployment setup and real-world evidence collection produces separate action\nrows instead of one mixed-scope handoff. Version 18 adds top-level\n`externalEvidenceBlockerSummary[]` rows that aggregate raw blocker IDs, goals,\ncommands, and artifact targets by `executionScope`, independently from grouped\nactions, so blocker debt is visible even before operators inspect\n`nextActions`. Version 17 is the first shape where\ngoal-level and report-level external-evidence blocker rows carry their own\n`executionScope`, so each blocker can be triaged as `local-refresh`,\n`deployment-environment`, or `real-world-evidence` without joining through\n`nextActions`. Version 16 is the first shape where\ntop-level `nextActionSummary[]` rows include distinct `commands` and\n`artifactTargets`, so each execution-scope lane is executable without joining\nthrough `nextActions`. Version 15 added `goalIds`, `goalTitles`,\n`goalCategories`, and `goalCount`, so each lane identifies the goals it affects\ninstead of only action and blocker totals. Version 14 added\n`blockedByExternalEvidenceGoals[].scopeBreakdown[]` to split each blocked goal's\naction IDs, next-action IDs, and blocker IDs by `local-refresh`,\n`deployment-environment`, and `real-world-evidence`, so operators can see\nwhether a named goal needs deploy wiring or real adoption/customer/30-day\nevidence. Version 13 localized\n`blockedByExternalEvidenceGoals[].actionBreakdown[].nextEvidenceRequirements`\nto the blocker IDs for that same goal, so shared commands do not inherit\nrequirements from unrelated goals. The schema now requires every blocked\nexternal-evidence goal to include at least one blocker id, next action id,\nexecution scope, remediation command, artifact target, and action-breakdown row,\nplus per-action blocker, artifact, and requirement counts, plus all three scope\nsummary rows, and generated blocker/action/scope/artifact arrays must be\nunique, so blocked goals cannot degrade into duplicated or prose-only handoffs.\nVersion 12 added `actionBreakdown` entries\nmapping each command to the goal-local blocker IDs it remediates, version 11\nadded exact `blockerIds`, version 10 added `nextActionIds`, `executionScopes`,\n`remediationCommands`, and `artifactTargets` to those rows, version 9 added the\nnamed blocked-goal records,\nversion 8 added `score.blockedByExternalEvidence`, version 7 added top-level\n`nextActionSummary` counts by execution scope; version 6 added\n`executionScope` on each grouped `nextActions` row, version 5 added a top-level\n`localGateStatus`, version 4 added machine-readable `artifactTargets`\non each grouped action row, version 3 added machine-readable\n`nextEvidenceRequirements`, version 2 was the first shape with top-level\n`nextActions`, and earlier version-1 artifacts are\npre-action-plan evidence handoffs. Each JSON artifact includes a `$schema` pointer to\n`docs/schemas/review-goals.schema.json` and each goal includes\n`evidenceArtifacts` paths that name where proof should land plus\n`evidenceArtifactStatuses` observations for the latest local file state\n(`missing`, `present`, `pass`, `failed`, `blocked`, and blocker counts). The\nservice exports the report version as `REVIEW_GOALS_REPORT_VERSION`, and the\nscript contract tests require the JSON schema `version.const` and emitted report\nversion to match that constant before the contract is accepted. Before the CLI\nprints or writes an artifact, it also compares the generated JSON shape against\nthe schema-required keys and every `additionalProperties: false` object promised\nby the schema for top-level report fields, score fields, goal rows, evidence\nrows, blocked-goal handoffs, next actions, and next-action summaries, so\nschema/report drift fails before a malformed handoff can be emitted. Goals\nthat depend on specific checks inside a larger artifact also include\n`evidenceArtifactCheckStatuses`; for example, launch readiness now preserves the\nspecific deployment-preflight and launch-review checks that are passing,\nfailing, or missing, managed-pilot packets derive entitlement/outreach/\nbilling/activation/support/KPI/retention checks from the packet fields, long-term and\nEra C exit-gate artifacts expose their SLO, uptime, adoption, p95, and KPI\nchecks, ActivityStreams artifacts expose their consumer and subscription checks,\nand Render validation/reconciliation service probes can be complete when their\n`/health` checks pass even if the broader production preflight is still failing\nfor unrelated storage or smoke reasons. Activity\nsyndication proof also preserves accepted and rejected callback evidence rows;\nsubscriptions only count when they are active external HTTPS callbacks whose\npublic, non-placeholder callback host matches the callback URL, are updated\ninside the evidence window, and cover Create, Update, and Delete. The coarse\nActivityStreams syndication readiness flag also requires the selected\n`activity.declaredConsumers` and `activity.durableSubscriptions` rows to pass,\nso a top-level ready artifact cannot hide missing durable subscriptions. Use the\nMarkdown file as the human handoff summary for the remaining external blockers.\nManaged-pilot billing checks also revalidate the invoice reference directly:\ndemo, fixture, internal, placeholder, sample, smoke, or test invoice tokens fail\nthe selected `pilot.billing.invoice` gate even if an artifact says billing is\nready. The coarse paid-pilot readiness flag also requires every selected\nmanaged-pilot check to pass: entitlement, billing, outreach, selected account,\nactivation milestones, support load, required KPIs, and retention signal.\nFor the Render validation/reconciliation goal, documented local fallback text is\nnot sufficient: the audit only counts the goal as deployed evidence when both\nselected service checks contain passing public HTTPS Render `/health` probe\nevidence; HTTP, non-health, placeholder, local, or private-network probe text\nremains a deployment blocker.\n\nBefore the CLI writes JSON or Markdown artifacts, it validates report invariants\nthat the JSON schema cannot express: score totals must match the goal list,\n`status`, `localGateStatus`, `strictGateStatus`,\n`strictGateFailureReasons`, every `strictGateFailureSummary[]` field, and the\nconsolidated `strictGateHandoff` must match those totals and blocker summaries,\n`score.blockedByExternalEvidence` must match the blocked-goal handoff count,\neach `blockerCount` must match its blocker IDs, blocked-goal action references\nmust point at known `nextActions`, and every `nextActionSummary` lane must match\nthe actions, commands, artifact targets, goals, and blockers in that same\nexecution scope. Each `nextActions[]` row must contain only blocker IDs whose\nraw external-evidence blocker has the same `executionScope`, so deployment\noperators cannot accidentally inherit customer, partner, or 30-day evidence\ndebt from a shared package command.\n\nSelected checks are readiness gates, not decorative annotations. A goal with\n`evidenceArtifactCheckStatuses` cannot be counted complete while any selected\ncheck is `fail`, `blocked`, `collecting`, `missing`, or otherwise not ready,\neven if a higher-level external flag was set.\nThe `launchEvidenceReady` coarse flag follows the same rule: it requires the\nselected launch-evidence, launch-review, and deployment-preflight rows to pass,\nso a hand-edited `status: ready` launch packet cannot hide a failing public URL,\nauth, worker scheduler, crawler-preview, Render probe, or SLO/tile check.\nLaunch readiness selects both `observability.publicBaseUrl` and\n`observability.socialPreviewBaseUrl` from deployment preflight, so a localhost,\nprotected, divergent, or non-HTTPS share URL stays visible as its own 10/10\nblocker before crawler-preview evidence is trusted.\nIt also selects `auth.secret`, `auth.github`, and `auth.routes`, so Auth.js\nsecret presence, GitHub OAuth credential presence, and deployed signin/session\nreachability all stay visible as distinct launch-readiness evidence.\nIt selects `runtime.workerScheduler` as well, preserving whether projection and\npublication drains are scheduled with `CRON_SECRET` or intentionally disabled\nbehind projection/publish scale flags before those workflows are enabled.\nIt selects `observability.uptime` from deployment preflight too, so the audit\nseparates \"a production-safe uptime source exists\" from the still-external\nrequirement to accumulate a passing 30-day uptime window; probe-based uptime\nmust point at the final public HTTPS deployment URL unless a Prometheus source\nis configured.\nIt also selects `evidence.validationService` and\n`evidence.reconciliationService` from deployment preflight, so launch readiness\nkeeps the deployed Render `/health` probes visible alongside the dedicated\nRender-services goal.\nThe 30-day SLO/uptime goal selects the Era C exit-gate checks `sota204P95`,\n`publicReadUptime`, `activityFeedAdoption`, and `sota26Kpis`, so performance\nmisses, insufficient uptime depth, missing external consumers, and KPI export\ngaps become their own real-world blocker rows with the\n`pnpm era-c:exit-gate:public` remediation command. Its coarse readiness flag\nalso requires the selected long-term runway rows and these Era C rows to pass,\nso a top-level ready runway artifact cannot hide a failing exit-gate check.\nIt also selects `smoke.crawlerPreview` from both launch evidence and launch\nreview packets, so social metadata cannot be accidentally dropped from the final\nlaunch-review gate while still appearing green in an earlier smoke step.\nLaunch evidence packets also carry per-step `nextEvidenceNeeded` and\n`remediation` fields for failed or skipped steps, so the top-level audit can be\nhanded to an operator with concrete commands and artifact paths instead of a\ngeneric \"launch readiness blocked\" note.\n`pnpm review:goals` preserves those fields inside\n`evidenceArtifactCheckStatuses` as `nextEvidenceNeeded`,\n`remediationCommand`, and `remediationArtifact`, which keeps the JSON schema,\nMarkdown handoff, and underlying launch packet aligned.\nWhen a source artifact uses launch-preflight or launch-review fields such as\n`recommendation`, `command`, or `evidencePath`, the collector normalizes those\ninto the same next-evidence/remediation fields. Derived pilot, long-term, and\nActivityStreams checks also receive default package-script and artifact targets\nso no selected blocker row is left as prose-only evidence debt.\nEach goal also includes `externalEvidenceBlockers`, a machine-readable list of\nthe unresolved real-world evidence requirements. It includes both coarse flags\nsuch as `launchEvidenceReady` and artifact-specific checks such as\n`artifacts/launch/launch-evidence-latest.json#hardening.securityDr`, with status,\nnext evidence, and remediation fields. Coarse external checks carry their own\nnext-evidence text, operator command, and artifact target, so production launch,\nRender service probe, long-term SLO/uptime, ActivityStreams syndication, and\npaid-pilot blockers can be handed off without inheriting misleading prose from\nthe enclosing goal or reverse-engineering the right package script.\nThe report also flattens all goal-level blockers into a top-level\n`externalEvidenceBlockers` array with `goalId`, `goalTitle`, `goalCategory`, and\n`goalStatus`, so CI, dashboards, and operator handoffs do not need to walk each\ngoal before listing the remaining real-world evidence.\nThe report also includes a top-level `nextActions` array that groups blockers by\nremediation command and unions every referenced artifact path into\n`artifactTargets`. A grouped action is keyed by both command and\n`executionScope`, so the same package script may appear once for deployment\nsetup and once for real-world proof without collapsing those lanes. A grouped\naction keeps every distinct evidence sentence from\nthe underlying blockers in `nextEvidenceRequirements`, while\n`nextEvidenceNeeded` stays as a compact human string, and the display `artifact`\nis generated from the same machine-readable target list. It also carries\n`executionScope` as `local-refresh`, `deployment-environment`, or\n`real-world-evidence`; `blockerIds` are goal-scoped references in the form\n`:` so a blocker reused by launch and a\nlong-term goal is not collapsed into one ambiguous id, and `blockerCount`\nmatches the number of scoped references in that list. The top-level\n`nextActionSummary` gives counts, action IDs, distinct commands, artifact\ntargets, blocker totals, distinct goal IDs, goal titles, goal categories, and\ngoal counts for each scope. That lets stale local reruns, deploy/env fixes, and\ncustomer or 30-day proof be queued separately. This lets one\n`pnpm launch:preflight:production` row preserve separate storage, SSL,\nrole-override, or service-probe requirements without forcing CI or dashboards to\nparse prose or path lists. Use this as the short operator run list; keep\n`externalEvidenceBlockers` for the full per-check audit trail.\nThe `score.blockedByExternalEvidence` metric combines `localComplete` and\n`externalEvidenceRequired`, making the total number of goals still blocked from\n10/10 visible even when one goal is marked `local-gate-complete` rather than\n`external-evidence-required`. The top-level `blockedByExternalEvidenceGoals`\narray names those same goals with id, title, category, status, next evidence,\nblocker count, exact blocker ids, grouped action ids, execution scopes, commands,\nartifact targets, a per-goal action breakdown, and a per-goal scope breakdown.\nThat lets an operator or dashboard list the four external-proof handoffs and see\nwhich command remediates which blocker, with goal-local evidence requirements\nand scope-specific blocker totals, without deriving them from the full goals\ntable or joining through `nextActions`.\nThe top-level `strictGateStatus` is the final gate result: it is `passed` only\nwhen the report status is `ten-of-ten-ready`; it remains `failed` for both\nmissing local gates and local-green reports that still need production,\npartner, customer, or 30-day evidence.\nThe top-level `strictGateFailureReasons[]` array is empty only when\n`strictGateStatus` is `passed`; otherwise it lists incomplete local gates and\nthe non-empty blocker lanes with blocker counts, goal counts, and remediation\ncommands.\nThe top-level `strictGateFailureSummary[]` array carries the same information in\nclosed structured rows, including `kind`, optional `scope`, `goalIds`,\n`remediationCommands`, and `artifactTargets`, so consumers can filter\ndeployment-environment blockers from real-world evidence blockers without\nparsing prose.\nThe top-level `strictGateHandoff` object consolidates those strict-gate rows\ninto one operator payload with summary IDs, execution scopes, blocker count,\nexact blocker IDs, exact next-action IDs, affected goal count and IDs/titles,\ndistinct remediation-command count, remediation commands, distinct artifact\ntarget count, artifact targets, distinct next-evidence requirement count, and\nevery distinct next-evidence requirement from the matching scoped actions. Its\n`scopeBreakdown[]` rows repeat those handoff fields per execution scope, so\ndeployment-environment work and real-world proof remain separable in dashboards\nand launch packets. Its arrays are empty only when the strict gate has passed.\n\nThe nightly Era C evidence workflow also runs `pnpm review:goals` and uploads\n`artifacts/review-goals/**` so the current 10/10 blocker state is captured with\nthe SLO, uptime, ActivityStreams, and KPI evidence packet.\nThe long-term packet also carries a `collectionPlan` with the daily workflow\ncadence, next scheduled run, missing distinct SLO/uptime days, missing external\nconsumer count, and earliest possible ready date when no hard SLO/uptime failure\nneeds operator intervention.\n\n## Status Meanings\n\n| Status | Meaning |\n|---|---|\n| `complete` | The local command, doc, test, and evidence checks for that goal are present and no external evidence is required. |\n| `local-gate-complete` | The local gate exists, but the goal still needs production evidence before it can be counted as truly complete. |\n| `external-evidence-required` | The local machinery exists, but real production, partner, or customer evidence is still missing. |\n| `incomplete` | A local command, doc, or test is missing and must be fixed before evidence collection is meaningful. |\n\n## Current Intent\n\nThe audit is allowed to fail `--check` until every real-world blocker is resolved.\nThat is intentional: the project should not claim 10/10 while SLO history,\nexternal ActivityStreams consumers, or real paid pilot evidence are still absent.\nThe local-gate command should pass during that interim state, proving the\nremaining failures are external evidence requirements rather than missing local\nscripts, docs, or tests.\n\nThe current local goal is `incomplete: 0`; after that, the remaining blockers must\ncome from real evidence. The latest local refresh pass also drives\n`nextActionSummary.local-refresh` to zero, so remaining action lanes are\ndeployment-environment setup and real-world evidence collection:\n\n- production launch readiness and long-term SLO/uptime depth,\n- real external ActivityStreams consumers with durable callback subscriptions,\n- real managed pilot support, activation, KPI, retention, and non-placeholder\n invoice-backed billing evidence.\n\n## Evidence Artifact Targets\n\nThe remaining external blockers are proven by these latest artifacts:\n\n| Blocker | Latest artifact targets |\n|---|---|\n| Launch readiness | `artifacts/launch/launch-evidence-latest.json`, `artifacts/launch/launch-review-latest.json`, `artifacts/launch/deployment-preflight-latest.json`, `artifacts/exit-gate/era-c-exit-gate-latest.json`; selected launch-review and deployment-preflight checks are listed in `evidenceArtifactCheckStatuses` |\n| 30-day SLO and uptime | `artifacts/long-term-evidence/long-term-evidence-runway-latest.json`, `artifacts/long-term-evidence/long-term-evidence-maintenance-latest.json`, `artifacts/long-term-evidence/long-term-evidence-maintenance-latest.md`, `artifacts/exit-gate/era-c-exit-gate-latest.json`, `monitoring/public-read-uptime-history.json`, `artifacts/performance/k6-slo-trend.json`; selected runway SLO/uptime/adoption checks plus Era C `sota204P95`, `publicReadUptime`, `activityFeedAdoption`, and `sota26Kpis` checks are listed in `evidenceArtifactCheckStatuses`, while the maintenance artifact names failed samples, clean passing days, and the earliest failure-free window date |\n| ActivityStreams syndication | `artifacts/activity-syndication/activity-syndication-evidence-latest.json`, `storage/activity-consumers.json`, `storage/activity-subscriptions.json`; selected declared-consumer and durable-subscription checks are listed in `evidenceArtifactCheckStatuses`, and accepted/rejected callback rows prove whether external HTTPS subscriptions use public non-placeholder callback hosts, match the callback URL, are fresh, and cover Create/Update/Delete |\n| Managed pilot evidence | `artifacts/pilot-evidence/pilot-evidence-latest.json`, `artifacts/pilot-evidence/pilot-evidence-latest.md`; selected entitlement, non-placeholder invoice-backed billing, outreach, activation, support-load, KPI, and retention-signal checks are listed in `evidenceArtifactCheckStatuses` |\n","sections":[{"level":2,"heading":"Status Meanings","anchor":"status-meanings"},{"level":2,"heading":"Current Intent","anchor":"current-intent"},{"level":2,"heading":"Evidence Artifact Targets","anchor":"evidence-artifact-targets"}],"html":"

Review Goals Audit

\n

`pnpm review:goals` is the 10/10 review-goal audit. It collects the local gates

\n

that came out of the project review and separates them from evidence that cannot

\n

be fabricated locally.

\n

Run it locally:

\n
\npnpm review:goals\npnpm review:goals:local\npnpm review:goals:check\n
\n

Use `pnpm review:goals:local` in CI when the expected state is "all local gates

\n

are complete, but real-world evidence is still pending." It exits non-zero only

\n

when `score.incomplete > 0`, and version-5+ artifacts expose the same result as

\n

top-level `localGateStatus: "passed" | "failed"`. Use `pnpm review:goals:check`

\n

for the final strict 10/10 gate; version-20+ artifacts expose that result as

\n

top-level `strictGateStatus: "passed" | "failed"`, and it must keep failing

\n

until production, partner, and customer evidence is actually present.

\n

The command writes timestamped JSON and Markdown evidence to

\n

`artifacts/review-goals/`, including `review-goals-latest.json` and

\n

`review-goals-latest.md`. JSON artifact `version: 45` adds top-level

\n

`readinessClaim`, a machine-readable boundary that names the allowed local-gate

\n

claim, the blocked strict-production claim, and the production proof scopes

\n

still needed before anyone can call the project strict 10/10 ready. Version 44 adds

\n

`blockedByExternalEvidenceGoals[].actionBreakdown[].blockerCount`,

\n

`artifactCount`, and `requirementCount`, so each blocked-goal action exposes

\n

dashboard-ready totals without counting its blocker, artifact, or requirement

\n

arrays. Version 42 adds

\n

`blockedByExternalEvidenceGoals[].scopeBreakdown[].nextActionIds`, so each

\n

named blocked goal can join scoped handoffs to grouped `nextActions` rows

\n

without interpreting legacy `actionIds`. Version 41 adds

\n

`blockedByExternalEvidenceGoals[].scopeCount`, so each named blocked goal shows

\n

whether its remaining work spans one or multiple execution lanes without

\n

counting `executionScopes[]`. Version 40 adds

\n

`blockedByExternalEvidenceGoals[].actionCount`, `commandCount`, and

\n

`artifactCount`, so each named blocked goal exposes dashboard-ready handoff

\n

totals without counting arrays. Version 39 adds

\n

`blockedByExternalEvidenceGoals[].nextEvidenceRequirements` and

\n

`requirementCount`, so each blocked-goal handoff carries its exact acceptance

\n

criteria directly. Version 38 adds

\n

`externalEvidenceBlockerSummary[].nextActionIds` and scoped `actionCount`, so

\n

each blocker-scope summary points directly at the grouped remediation actions.

\n

Version 37 adds

\n

`externalEvidenceBlockerSummary[].nextEvidenceRequirements` and scoped

\n

`requirementCount`, so each blocker-scope summary carries its acceptance

\n

criteria directly. Version 36 adds `nextActionSummary[].actionCount`, so each

\n

execution-scope lane exposes its action total directly while legacy `count`

\n

remains for compatibility. Version 35 adds top-level

\n

`strictGateHandoff.nextActionCount` and scoped

\n

`strictGateHandoff.scopeBreakdown[].nextActionCount`, so strict handoff

\n

dashboards can display executable action totals without counting action ID

\n

arrays. Version 34 adds scoped

\n

`blockedByExternalEvidenceGoals[].scopeBreakdown[].remediationCommands`,

\n

`artifactTargets`, and `nextEvidenceRequirements`, so per-goal blocked

\n

handoffs carry the executable operator payload without joining back through

\n

`actionBreakdown`. Version 33 adds

\n

`blockedByExternalEvidenceGoals[].scopeBreakdown[].actionCount`,

\n

`commandCount`, `artifactCount`, and `requirementCount`, so per-goal blocked

\n

handoffs can display scoped action, command, artifact, and acceptance-criteria

\n

totals without counting nested arrays. Version 32 adds

\n

`strictGateHandoff.requirementCount` and scoped

\n

`strictGateHandoff.scopeBreakdown[].requirementCount`, so dashboards can display

\n

distinct next-evidence acceptance criteria without counting long requirement

\n

arrays; these counts are deduplicated and can be lower than blocker counts.

\n

Version 31 adds `strictGateHandoff.artifactCount` and scoped

\n

`strictGateHandoff.scopeBreakdown[].artifactCount`, so dashboards can display

\n

distinct evidence-artifact target totals without counting arrays. Version 30

\n

adds `strictGateHandoff.commandCount` and scoped

\n

`strictGateHandoff.scopeBreakdown[].commandCount`, so dashboards can display

\n

distinct remediation-command totals without counting arrays; scoped action

\n

counts remain separate because one command can appear in more than one

\n

execution scope. Version 29 adds `strictGateHandoff.goalCount` and scoped

\n

`strictGateHandoff.scopeBreakdown[].goalCount`, so the strict-gate operator

\n

payload exposes affected-goal totals without consumers counting arrays. Version

\n

28 adds

\n

`strictGateHandoff.nextActionIds[]` and scoped

\n

`strictGateHandoff.scopeBreakdown[].nextActionIds[]`, so the strict-gate

\n

operator payload points directly at the executable `nextActions[]` rows without

\n

reconstructing command/scope keys. Version 27 adds

\n

`strictGateHandoff.blockerIds[]` and scoped

\n

`strictGateHandoff.scopeBreakdown[].blockerIds[]`, so the strict-gate operator

\n

payload names the exact failing checks without requiring consumers to join

\n

through goal rows or blocker summaries. Version 26 adds

\n

`strictGateHandoff.scopeBreakdown[]`, so the strict-gate operator payload keeps

\n

deployment-environment and real-world-evidence commands, artifacts, blockers,

\n

goals, and evidence requirements separated without another join. Version 25 adds

\n

`strictGateHandoff.nextEvidenceRequirements[]`, so the consolidated strict-gate

\n

operator payload includes the exact evidence sentences from the scoped action

\n

rows, not only commands and artifact paths. Version 24 adds top-level

\n

`strictGateHandoff`, a machine-readable strict-gate operator handoff that

\n

consolidates failing summary IDs, execution scopes, blocker count, affected

\n

goals, remediation commands, and artifact targets without requiring consumers

\n

to re-join the summary rows. Version 23 extends the runtime invariant guard so

\n

every `strictGateFailureSummary[]` field must match the derived strict-gate

\n

rows, not just the row IDs. Version 22 adds top-level

\n

`strictGateFailureSummary[]`, a structured dashboard-ready form of strict gate

\n

failure rows with kind, scope, blocker counts, goals, commands, artifacts, and

\n

the matching human reason. Version 21 adds top-level

\n

`strictGateFailureReasons[]`, so a failed strict 10/10 gate names the local,

\n

deployment-environment, and real-world evidence lanes that still block launch

\n

readiness instead of forcing dashboards to reconstruct those sentences. Version

\n

20 adds top-level `strictGateStatus`, the machine-readable result for

\n

`pnpm review:goals:check`, so CI, dashboards, and launch handoffs do not have

\n

to infer strict 10/10 readiness from the broader status string. Version 19 keys

\n

`nextActions` by

\n

remediation command plus `executionScope`, so a command that appears in both

\n

deployment setup and real-world evidence collection produces separate action

\n

rows instead of one mixed-scope handoff. Version 18 adds top-level

\n

`externalEvidenceBlockerSummary[]` rows that aggregate raw blocker IDs, goals,

\n

commands, and artifact targets by `executionScope`, independently from grouped

\n

actions, so blocker debt is visible even before operators inspect

\n

`nextActions`. Version 17 is the first shape where

\n

goal-level and report-level external-evidence blocker rows carry their own

\n

`executionScope`, so each blocker can be triaged as `local-refresh`,

\n

`deployment-environment`, or `real-world-evidence` without joining through

\n

`nextActions`. Version 16 is the first shape where

\n

top-level `nextActionSummary[]` rows include distinct `commands` and

\n

`artifactTargets`, so each execution-scope lane is executable without joining

\n

through `nextActions`. Version 15 added `goalIds`, `goalTitles`,

\n

`goalCategories`, and `goalCount`, so each lane identifies the goals it affects

\n

instead of only action and blocker totals. Version 14 added

\n

`blockedByExternalEvidenceGoals[].scopeBreakdown[]` to split each blocked goal's

\n

action IDs, next-action IDs, and blocker IDs by `local-refresh`,

\n

`deployment-environment`, and `real-world-evidence`, so operators can see

\n

whether a named goal needs deploy wiring or real adoption/customer/30-day

\n

evidence. Version 13 localized

\n

`blockedByExternalEvidenceGoals[].actionBreakdown[].nextEvidenceRequirements`

\n

to the blocker IDs for that same goal, so shared commands do not inherit

\n

requirements from unrelated goals. The schema now requires every blocked

\n

external-evidence goal to include at least one blocker id, next action id,

\n

execution scope, remediation command, artifact target, and action-breakdown row,

\n

plus per-action blocker, artifact, and requirement counts, plus all three scope

\n

summary rows, and generated blocker/action/scope/artifact arrays must be

\n

unique, so blocked goals cannot degrade into duplicated or prose-only handoffs.

\n

Version 12 added `actionBreakdown` entries

\n

mapping each command to the goal-local blocker IDs it remediates, version 11

\n

added exact `blockerIds`, version 10 added `nextActionIds`, `executionScopes`,

\n

`remediationCommands`, and `artifactTargets` to those rows, version 9 added the

\n

named blocked-goal records,

\n

version 8 added `score.blockedByExternalEvidence`, version 7 added top-level

\n

`nextActionSummary` counts by execution scope; version 6 added

\n

`executionScope` on each grouped `nextActions` row, version 5 added a top-level

\n

`localGateStatus`, version 4 added machine-readable `artifactTargets`

\n

on each grouped action row, version 3 added machine-readable

\n

`nextEvidenceRequirements`, version 2 was the first shape with top-level

\n

`nextActions`, and earlier version-1 artifacts are

\n

pre-action-plan evidence handoffs. Each JSON artifact includes a `$schema` pointer to

\n

`docs/schemas/review-goals.schema.json` and each goal includes

\n

`evidenceArtifacts` paths that name where proof should land plus

\n

`evidenceArtifactStatuses` observations for the latest local file state

\n

(`missing`, `present`, `pass`, `failed`, `blocked`, and blocker counts). The

\n

service exports the report version as `REVIEW_GOALS_REPORT_VERSION`, and the

\n

script contract tests require the JSON schema `version.const` and emitted report

\n

version to match that constant before the contract is accepted. Before the CLI

\n

prints or writes an artifact, it also compares the generated JSON shape against

\n

the schema-required keys and every `additionalProperties: false` object promised

\n

by the schema for top-level report fields, score fields, goal rows, evidence

\n

rows, blocked-goal handoffs, next actions, and next-action summaries, so

\n

schema/report drift fails before a malformed handoff can be emitted. Goals

\n

that depend on specific checks inside a larger artifact also include

\n

`evidenceArtifactCheckStatuses`; for example, launch readiness now preserves the

\n

specific deployment-preflight and launch-review checks that are passing,

\n

failing, or missing, managed-pilot packets derive entitlement/outreach/

\n

billing/activation/support/KPI/retention checks from the packet fields, long-term and

\n

Era C exit-gate artifacts expose their SLO, uptime, adoption, p95, and KPI

\n

checks, ActivityStreams artifacts expose their consumer and subscription checks,

\n

and Render validation/reconciliation service probes can be complete when their

\n

`/health` checks pass even if the broader production preflight is still failing

\n

for unrelated storage or smoke reasons. Activity

\n

syndication proof also preserves accepted and rejected callback evidence rows;

\n

subscriptions only count when they are active external HTTPS callbacks whose

\n

public, non-placeholder callback host matches the callback URL, are updated

\n

inside the evidence window, and cover Create, Update, and Delete. The coarse

\n

ActivityStreams syndication readiness flag also requires the selected

\n

`activity.declaredConsumers` and `activity.durableSubscriptions` rows to pass,

\n

so a top-level ready artifact cannot hide missing durable subscriptions. Use the

\n

Markdown file as the human handoff summary for the remaining external blockers.

\n

Managed-pilot billing checks also revalidate the invoice reference directly:

\n

demo, fixture, internal, placeholder, sample, smoke, or test invoice tokens fail

\n

the selected `pilot.billing.invoice` gate even if an artifact says billing is

\n

ready. The coarse paid-pilot readiness flag also requires every selected

\n

managed-pilot check to pass: entitlement, billing, outreach, selected account,

\n

activation milestones, support load, required KPIs, and retention signal.

\n

For the Render validation/reconciliation goal, documented local fallback text is

\n

not sufficient: the audit only counts the goal as deployed evidence when both

\n

selected service checks contain passing public HTTPS Render `/health` probe

\n

evidence; HTTP, non-health, placeholder, local, or private-network probe text

\n

remains a deployment blocker.

\n

Before the CLI writes JSON or Markdown artifacts, it validates report invariants

\n

that the JSON schema cannot express: score totals must match the goal list,

\n

`status`, `localGateStatus`, `strictGateStatus`,

\n

`strictGateFailureReasons`, every `strictGateFailureSummary[]` field, and the

\n

consolidated `strictGateHandoff` must match those totals and blocker summaries,

\n

`score.blockedByExternalEvidence` must match the blocked-goal handoff count,

\n

each `blockerCount` must match its blocker IDs, blocked-goal action references

\n

must point at known `nextActions`, and every `nextActionSummary` lane must match

\n

the actions, commands, artifact targets, goals, and blockers in that same

\n

execution scope. Each `nextActions[]` row must contain only blocker IDs whose

\n

raw external-evidence blocker has the same `executionScope`, so deployment

\n

operators cannot accidentally inherit customer, partner, or 30-day evidence

\n

debt from a shared package command.

\n

Selected checks are readiness gates, not decorative annotations. A goal with

\n

`evidenceArtifactCheckStatuses` cannot be counted complete while any selected

\n

check is `fail`, `blocked`, `collecting`, `missing`, or otherwise not ready,

\n

even if a higher-level external flag was set.

\n

The `launchEvidenceReady` coarse flag follows the same rule: it requires the

\n

selected launch-evidence, launch-review, and deployment-preflight rows to pass,

\n

so a hand-edited `status: ready` launch packet cannot hide a failing public URL,

\n

auth, worker scheduler, crawler-preview, Render probe, or SLO/tile check.

\n

Launch readiness selects both `observability.publicBaseUrl` and

\n

`observability.socialPreviewBaseUrl` from deployment preflight, so a localhost,

\n

protected, divergent, or non-HTTPS share URL stays visible as its own 10/10

\n

blocker before crawler-preview evidence is trusted.

\n

It also selects `auth.secret`, `auth.github`, and `auth.routes`, so Auth.js

\n

secret presence, GitHub OAuth credential presence, and deployed signin/session

\n

reachability all stay visible as distinct launch-readiness evidence.

\n

It selects `runtime.workerScheduler` as well, preserving whether projection and

\n

publication drains are scheduled with `CRON_SECRET` or intentionally disabled

\n

behind projection/publish scale flags before those workflows are enabled.

\n

It selects `observability.uptime` from deployment preflight too, so the audit

\n

separates "a production-safe uptime source exists" from the still-external

\n

requirement to accumulate a passing 30-day uptime window; probe-based uptime

\n

must point at the final public HTTPS deployment URL unless a Prometheus source

\n

is configured.

\n

It also selects `evidence.validationService` and

\n

`evidence.reconciliationService` from deployment preflight, so launch readiness

\n

keeps the deployed Render `/health` probes visible alongside the dedicated

\n

Render-services goal.

\n

The 30-day SLO/uptime goal selects the Era C exit-gate checks `sota204P95`,

\n

`publicReadUptime`, `activityFeedAdoption`, and `sota26Kpis`, so performance

\n

misses, insufficient uptime depth, missing external consumers, and KPI export

\n

gaps become their own real-world blocker rows with the

\n

`pnpm era-c:exit-gate:public` remediation command. Its coarse readiness flag

\n

also requires the selected long-term runway rows and these Era C rows to pass,

\n

so a top-level ready runway artifact cannot hide a failing exit-gate check.

\n

It also selects `smoke.crawlerPreview` from both launch evidence and launch

\n

review packets, so social metadata cannot be accidentally dropped from the final

\n

launch-review gate while still appearing green in an earlier smoke step.

\n

Launch evidence packets also carry per-step `nextEvidenceNeeded` and

\n

`remediation` fields for failed or skipped steps, so the top-level audit can be

\n

handed to an operator with concrete commands and artifact paths instead of a

\n

generic "launch readiness blocked" note.

\n

`pnpm review:goals` preserves those fields inside

\n

`evidenceArtifactCheckStatuses` as `nextEvidenceNeeded`,

\n

`remediationCommand`, and `remediationArtifact`, which keeps the JSON schema,

\n

Markdown handoff, and underlying launch packet aligned.

\n

When a source artifact uses launch-preflight or launch-review fields such as

\n

`recommendation`, `command`, or `evidencePath`, the collector normalizes those

\n

into the same next-evidence/remediation fields. Derived pilot, long-term, and

\n

ActivityStreams checks also receive default package-script and artifact targets

\n

so no selected blocker row is left as prose-only evidence debt.

\n

Each goal also includes `externalEvidenceBlockers`, a machine-readable list of

\n

the unresolved real-world evidence requirements. It includes both coarse flags

\n

such as `launchEvidenceReady` and artifact-specific checks such as

\n

`artifacts/launch/launch-evidence-latest.json#hardening.securityDr`, with status,

\n

next evidence, and remediation fields. Coarse external checks carry their own

\n

next-evidence text, operator command, and artifact target, so production launch,

\n

Render service probe, long-term SLO/uptime, ActivityStreams syndication, and

\n

paid-pilot blockers can be handed off without inheriting misleading prose from

\n

the enclosing goal or reverse-engineering the right package script.

\n

The report also flattens all goal-level blockers into a top-level

\n

`externalEvidenceBlockers` array with `goalId`, `goalTitle`, `goalCategory`, and

\n

`goalStatus`, so CI, dashboards, and operator handoffs do not need to walk each

\n

goal before listing the remaining real-world evidence.

\n

The report also includes a top-level `nextActions` array that groups blockers by

\n

remediation command and unions every referenced artifact path into

\n

`artifactTargets`. A grouped action is keyed by both command and

\n

`executionScope`, so the same package script may appear once for deployment

\n

setup and once for real-world proof without collapsing those lanes. A grouped

\n

action keeps every distinct evidence sentence from

\n

the underlying blockers in `nextEvidenceRequirements`, while

\n

`nextEvidenceNeeded` stays as a compact human string, and the display `artifact`

\n

is generated from the same machine-readable target list. It also carries

\n

`executionScope` as `local-refresh`, `deployment-environment`, or

\n

`real-world-evidence`; `blockerIds` are goal-scoped references in the form

\n

`<goalId>:<externalCheckOrArtifactCheckId>` so a blocker reused by launch and a

\n

long-term goal is not collapsed into one ambiguous id, and `blockerCount`

\n

matches the number of scoped references in that list. The top-level

\n

`nextActionSummary` gives counts, action IDs, distinct commands, artifact

\n

targets, blocker totals, distinct goal IDs, goal titles, goal categories, and

\n

goal counts for each scope. That lets stale local reruns, deploy/env fixes, and

\n

customer or 30-day proof be queued separately. This lets one

\n

`pnpm launch:preflight:production` row preserve separate storage, SSL,

\n

role-override, or service-probe requirements without forcing CI or dashboards to

\n

parse prose or path lists. Use this as the short operator run list; keep

\n

`externalEvidenceBlockers` for the full per-check audit trail.

\n

The `score.blockedByExternalEvidence` metric combines `localComplete` and

\n

`externalEvidenceRequired`, making the total number of goals still blocked from

\n

10/10 visible even when one goal is marked `local-gate-complete` rather than

\n

`external-evidence-required`. The top-level `blockedByExternalEvidenceGoals`

\n

array names those same goals with id, title, category, status, next evidence,

\n

blocker count, exact blocker ids, grouped action ids, execution scopes, commands,

\n

artifact targets, a per-goal action breakdown, and a per-goal scope breakdown.

\n

That lets an operator or dashboard list the four external-proof handoffs and see

\n

which command remediates which blocker, with goal-local evidence requirements

\n

and scope-specific blocker totals, without deriving them from the full goals

\n

table or joining through `nextActions`.

\n

The top-level `strictGateStatus` is the final gate result: it is `passed` only

\n

when the report status is `ten-of-ten-ready`; it remains `failed` for both

\n

missing local gates and local-green reports that still need production,

\n

partner, customer, or 30-day evidence.

\n

The top-level `strictGateFailureReasons[]` array is empty only when

\n

`strictGateStatus` is `passed`; otherwise it lists incomplete local gates and

\n

the non-empty blocker lanes with blocker counts, goal counts, and remediation

\n

commands.

\n

The top-level `strictGateFailureSummary[]` array carries the same information in

\n

closed structured rows, including `kind`, optional `scope`, `goalIds`,

\n

`remediationCommands`, and `artifactTargets`, so consumers can filter

\n

deployment-environment blockers from real-world evidence blockers without

\n

parsing prose.

\n

The top-level `strictGateHandoff` object consolidates those strict-gate rows

\n

into one operator payload with summary IDs, execution scopes, blocker count,

\n

exact blocker IDs, exact next-action IDs, affected goal count and IDs/titles,

\n

distinct remediation-command count, remediation commands, distinct artifact

\n

target count, artifact targets, distinct next-evidence requirement count, and

\n

every distinct next-evidence requirement from the matching scoped actions. Its

\n

`scopeBreakdown[]` rows repeat those handoff fields per execution scope, so

\n

deployment-environment work and real-world proof remain separable in dashboards

\n

and launch packets. Its arrays are empty only when the strict gate has passed.

\n

The nightly Era C evidence workflow also runs `pnpm review:goals` and uploads

\n

`artifacts/review-goals/**` so the current 10/10 blocker state is captured with

\n

the SLO, uptime, ActivityStreams, and KPI evidence packet.

\n

The long-term packet also carries a `collectionPlan` with the daily workflow

\n

cadence, next scheduled run, missing distinct SLO/uptime days, missing external

\n

consumer count, and earliest possible ready date when no hard SLO/uptime failure

\n

needs operator intervention.

\n

Status Meanings

\n

| Status | Meaning |

\n

|---|---|

\n

| `complete` | The local command, doc, test, and evidence checks for that goal are present and no external evidence is required. |

\n

| `local-gate-complete` | The local gate exists, but the goal still needs production evidence before it can be counted as truly complete. |

\n

| `external-evidence-required` | The local machinery exists, but real production, partner, or customer evidence is still missing. |

\n

| `incomplete` | A local command, doc, or test is missing and must be fixed before evidence collection is meaningful. |

\n

Current Intent

\n

The audit is allowed to fail `--check` until every real-world blocker is resolved.

\n

That is intentional: the project should not claim 10/10 while SLO history,

\n

external ActivityStreams consumers, or real paid pilot evidence are still absent.

\n

The local-gate command should pass during that interim state, proving the

\n

remaining failures are external evidence requirements rather than missing local

\n

scripts, docs, or tests.

\n

The current local goal is `incomplete: 0`; after that, the remaining blockers must

\n

come from real evidence. The latest local refresh pass also drives

\n

`nextActionSummary.local-refresh` to zero, so remaining action lanes are

\n

deployment-environment setup and real-world evidence collection:

\n

invoice-backed billing evidence.

\n\n

Evidence Artifact Targets

\n

The remaining external blockers are proven by these latest artifacts:

\n

| Blocker | Latest artifact targets |

\n

|---|---|

\n

| Launch readiness | `artifacts/launch/launch-evidence-latest.json`, `artifacts/launch/launch-review-latest.json`, `artifacts/launch/deployment-preflight-latest.json`, `artifacts/exit-gate/era-c-exit-gate-latest.json`; selected launch-review and deployment-preflight checks are listed in `evidenceArtifactCheckStatuses` |

\n

| 30-day SLO and uptime | `artifacts/long-term-evidence/long-term-evidence-runway-latest.json`, `artifacts/long-term-evidence/long-term-evidence-maintenance-latest.json`, `artifacts/long-term-evidence/long-term-evidence-maintenance-latest.md`, `artifacts/exit-gate/era-c-exit-gate-latest.json`, `monitoring/public-read-uptime-history.json`, `artifacts/performance/k6-slo-trend.json`; selected runway SLO/uptime/adoption checks plus Era C `sota204P95`, `publicReadUptime`, `activityFeedAdoption`, and `sota26Kpis` checks are listed in `evidenceArtifactCheckStatuses`, while the maintenance artifact names failed samples, clean passing days, and the earliest failure-free window date |

\n

| ActivityStreams syndication | `artifacts/activity-syndication/activity-syndication-evidence-latest.json`, `storage/activity-consumers.json`, `storage/activity-subscriptions.json`; selected declared-consumer and durable-subscription checks are listed in `evidenceArtifactCheckStatuses`, and accepted/rejected callback rows prove whether external HTTPS subscriptions use public non-placeholder callback hosts, match the callback URL, are fresh, and cover Create/Update/Delete |

\n

| Managed pilot evidence | `artifacts/pilot-evidence/pilot-evidence-latest.json`, `artifacts/pilot-evidence/pilot-evidence-latest.md`; selected entitlement, non-placeholder invoice-backed billing, outreach, activation, support-load, KPI, and retention-signal checks are listed in `evidenceArtifactCheckStatuses` |

","updatedAt":"2018-10-20T01:46:40.000Z","checksum":"cc1459601a262f85b08064eef8b2d87f7f1ac758e728310d3e11d47ad21da3a4","checksumPrefix":"cc1459601a26","anchorCount":3,"lineCount":373,"rawUrl":"/api/docs/content?path=ops%2Freview-goals.md","htmlUrl":"/docs?doc=ops%2Freview-goals.md","apiUrl":"/api/docs/content?path=ops%2Freview-goals.md"}