@agent-native/core 0.214.0 → 0.216.0

package/dist/shared/consent.js

@@ -0,0 +1,145 @@
+/**
+ * Cookie consent for the regions that need it. The regions and categories
+ * follow builder.io's consent banner: visitors in these countries opt in, and
+ * every other visitor is tracked as before, with no banner.
+ */
+/**
+ * Countries that see the banner: builder.io's "GDPR" rule, i.e. the EU, the
+ * rest of the EEA, Monaco, San Marino, Åland and France's overseas regions.
+ * The UK and Switzerland are not on it, matching builder.io.
+ */
+const CONSENT_REGION_COUNTRY_CODES = new Set([
+    "AT",
+    "AX",
+    "BE",
+    "BG",
+    "CY",
+    "CZ",
+    "DE",
+    "DK",
+    "EE",
+    "ES",
+    "FI",
+    "FR",
+    "GF",
+    "GP",
+    "GR",
+    "HR",
+    "HU",
+    "IE",
+    "IS",
+    "IT",
+    "LI",
+    "LT",
+    "LU",
+    "LV",
+    "MC",
+    "MF",
+    "MQ",
+    "MT",
+    "NL",
+    "NO",
+    "PL",
+    "PT",
+    "RE",
+    "RO",
+    "SE",
+    "SI",
+    "SK",
+    "SM",
+    "YT",
+]);
+/** The IANA zones of those countries, for a request with no country header. */
+const CONSENT_REGION_TIME_ZONES = new Set([
+    "Africa/Ceuta",
+    "America/Cayenne",
+    "America/Guadeloupe",
+    "America/Marigot",
+    "America/Martinique",
+    "Asia/Famagusta",
+    "Asia/Nicosia",
+    "Atlantic/Azores",
+    "Atlantic/Canary",
+    "Atlantic/Madeira",
+    "Atlantic/Reykjavik",
+    "Europe/Amsterdam",
+    "Europe/Athens",
+    "Europe/Berlin",
+    "Europe/Bratislava",
+    "Europe/Brussels",
+    "Europe/Bucharest",
+    "Europe/Budapest",
+    "Europe/Busingen",
+    "Europe/Copenhagen",
+    "Europe/Dublin",
+    "Europe/Helsinki",
+    "Europe/Lisbon",
+    "Europe/Ljubljana",
+    "Europe/Luxembourg",
+    "Europe/Madrid",
+    "Europe/Malta",
+    "Europe/Mariehamn",
+    "Europe/Monaco",
+    "Europe/Nicosia",
+    "Europe/Oslo",
+    "Europe/Paris",
+    "Europe/Prague",
+    "Europe/Riga",
+    "Europe/Rome",
+    "Europe/San_Marino",
+    "Europe/Sofia",
+    "Europe/Stockholm",
+    "Europe/Tallinn",
+    "Europe/Vaduz",
+    "Europe/Vienna",
+    "Europe/Vilnius",
+    "Europe/Warsaw",
+    "Europe/Zagreb",
+    "Indian/Mayotte",
+    "Indian/Reunion",
+    "CET",
+    "EET",
+    "Eire",
+    "Iceland",
+    "MET",
+    "Poland",
+    "Portugal",
+    "WET",
+]);
+export function isConsentRegionCountry(code) {
+    return CONSENT_REGION_COUNTRY_CODES.has(code?.trim().toUpperCase() ?? "");
+}
+export function isConsentRegionTimeZone(timeZone) {
+    return !!timeZone && CONSENT_REGION_TIME_ZONES.has(timeZone);
+}
+export const CONSENT_COOKIE_NAME = "an_consent";
+/** Asked again a year later, like builder.io. */
+export const CONSENT_COOKIE_LIFETIME_SECONDS = 365 * 24 * 60 * 60;
+export const CONSENT_REGION_PATH = "/_agent-native/auth/consent-region";
+export const CONSENT_PATH = "/_agent-native/auth/consent";
+/**
+ * One choice covers the site and every app on agent-native.com. The browser
+ * and the server must agree, or the two copies become two cookies.
+ */
+export function consentCookieDomain(hostname) {
+    const host = hostname.toLowerCase();
+    return host === "agent-native.com" || host.endsWith(".agent-native.com")
+        ? "agent-native.com"
+        : null;
+}
+const CONSENT_COOKIE_VERSION = "1";
+/** `1.p1.t0`: version, then one flag per category. */
+export function serializeConsent(choice) {
+    return [
+        CONSENT_COOKIE_VERSION,
+        `p${choice.performance ? 1 : 0}`,
+        `t${choice.targeting ? 1 : 0}`,
+    ].join(".");
+}
+/** The stored choice, or `null` when there is none this version can read. */
+export function parseConsent(value) {
+    const match = /^1\.p([01])\.t([01])$/.exec(value?.trim() ?? "");
+    if (!match)
+        return null;
+    return { performance: match[1] === "1", targeting: match[2] === "1" };
+}

package/dist/shared/first-touch-persistence.d.ts

@@ -0,0 +1,31 @@
+import { type AttributionTouch } from "./attribution-source.js";
+/**
+ * The durable copy of first touch. Our server sets it, because Safari caps
+ * cookies written by page JavaScript at seven days; the browser's own `an_ft`
+ * cookie and localStorage copy stay the immediate, 30-day copies. Signup and
+ * the browser both pick between the copies with `preferFirstTouch`, so they
+ * agree on which visit is first touch.
+ */
+export declare const FIRST_TOUCH_SERVER_COOKIE_NAME = "an_fts";
+export declare const FIRST_TOUCH_SERVER_COOKIE_VERSION = "1";
+export declare const FIRST_TOUCH_SERVER_PATH = "/_agent-native/auth/attribution";
+/** Counted from the first visit, never extended by later ones. */
+export declare const FIRST_TOUCH_SERVER_LIFETIME_SECONDS: number;
+/** `name=value` budget, so this and the browser's cookies fit one header. */
+export declare const FIRST_TOUCH_SERVER_COOKIE_MAX_BYTES = 1500;
+export interface TimedFirstTouch extends AttributionTouch {
+    landed_at?: string;
+}
+/**
+ * Which of two records is first touch: the first visit that had a source,
+ * else the first visit. `incumbent` wins a tie, so a copy never displaces the
+ * value it came from.
+ */
+export declare function preferFirstTouch<T extends TimedFirstTouch>(incumbent: T | null | undefined, challenger: T | null | undefined): T | null;
+/** Whether two records are the same visit, however each copy was trimmed. */
+export declare function isSameFirstTouch(a: TimedFirstTouch | null | undefined, b: TimedFirstTouch | null | undefined): boolean;
+/**
+ * When the durable copy expires: a year after the visit, or `null` once that
+ * year is over. A missing or future visit time counts from now.
+ */
+export declare function firstTouchServerExpiry(touch: TimedFirstTouch, now?: number): Date | null;

package/dist/shared/first-touch-persistence.js

@@ -0,0 +1,53 @@
+import { hasAttributionSource, } from "./attribution-source.js";
+/**
+ * The durable copy of first touch. Our server sets it, because Safari caps
+ * cookies written by page JavaScript at seven days; the browser's own `an_ft`
+ * cookie and localStorage copy stay the immediate, 30-day copies. Signup and
+ * the browser both pick between the copies with `preferFirstTouch`, so they
+ * agree on which visit is first touch.
+ */
+export const FIRST_TOUCH_SERVER_COOKIE_NAME = "an_fts";
+export const FIRST_TOUCH_SERVER_COOKIE_VERSION = "1";
+export const FIRST_TOUCH_SERVER_PATH = "/_agent-native/auth/attribution";
+/** Counted from the first visit, never extended by later ones. */
+export const FIRST_TOUCH_SERVER_LIFETIME_SECONDS = 365 * 24 * 60 * 60;
+/** `name=value` budget, so this and the browser's cookies fit one header. */
+export const FIRST_TOUCH_SERVER_COOKIE_MAX_BYTES = 1500;
+// A record with no readable visit time was trimmed to fit its cookie, so it
+// was stored before any dated record it is compared with.
+function landedAtMs(touch) {
+    const time = Date.parse(touch.landed_at ?? "");
+    return Number.isFinite(time) ? time : Number.NEGATIVE_INFINITY;
+}
+/**
+ * Which of two records is first touch: the first visit that had a source,
+ * else the first visit. `incumbent` wins a tie, so a copy never displaces the
+ * value it came from.
+ */
+export function preferFirstTouch(incumbent, challenger) {
+    if (!incumbent)
+        return challenger ?? null;
+    if (!challenger)
+        return incumbent;
+    const incumbentSourced = hasAttributionSource(incumbent);
+    if (incumbentSourced !== hasAttributionSource(challenger)) {
+        return incumbentSourced ? incumbent : challenger;
+    }
+    return landedAtMs(challenger) < landedAtMs(incumbent)
+        ? challenger
+        : incumbent;
+}
+/** Whether two records are the same visit, however each copy was trimmed. */
+export function isSameFirstTouch(a, b) {
+    return !!a?.landed_at && a.landed_at === b?.landed_at;
+}
+/**
+ * When the durable copy expires: a year after the visit, or `null` once that
+ * year is over. A missing or future visit time counts from now.
+ */
+export function firstTouchServerExpiry(touch, now = Date.now()) {
+    const landed = Date.parse(touch.landed_at ?? "");
+    const start = Number.isFinite(landed) && landed <= now ? landed : now;
+    const expires = start + FIRST_TOUCH_SERVER_LIFETIME_SECONDS * 1000;
+    return expires > now ? new Date(expires) : null;
+}

package/dist/sharing/actions/set-resource-visibility.js

@@ -29,6 +29,11 @@ export default defineAction({
         const access = await assertAccess(args.resourceType, args.resourceId, "admin", undefined, { skipResourceBody: true });
         return access.resource.visibility !== "public";
     },
+    mcpAnnotations: {
+        readOnlyHint: false,
+        destructiveHint: true,
+        openWorldHint: true,
+    },
     run: async (args, ctx) => {
         assertWidgetShareWriteGrant(ctx, "set-resource-visibility", args);
         const reg = requireShareableResource(args.resourceType);

package/dist/sharing/actions/share-resource.js

@@ -124,6 +124,11 @@ export default defineAction({
             .describe("Optional short note included in the notification email to an individual recipient."),
     }),
     needsApproval: needsExternalShareApproval,
+    mcpAnnotations: {
+        readOnlyHint: false,
+        destructiveHint: true,
+        openWorldHint: true,
+    },
     run: async (args, ctx) => {
         assertWidgetShareWriteGrant(ctx, "share-resource", args);
         const reg = requireShareableResource(args.resourceType);

package/dist/sharing/actions/unshare-resource.js

@@ -26,6 +26,11 @@ export default defineAction({
         principalType: z.enum(["user", "group", "org"]),
         principalId: z.string(),
     }),
+    mcpAnnotations: {
+        readOnlyHint: false,
+        destructiveHint: true,
+        openWorldHint: false,
+    },
     run: async (args, ctx) => {
         assertWidgetShareWriteGrant(ctx, "unshare-resource", args);
         const reg = requireShareableResource(args.resourceType);

package/dist/templates/chat/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/dist/templates/default/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/dist/templates/factory/.agents/skills/review-latest-feedback/SKILL.md

@@ -21,25 +21,15 @@ Four phases, in order. Phase 0 comes before any investigation, not after.
 2. **Fix** what the evidence actually proves, at the owning boundary.
 3. **Reply** with useful questions, then recap.
 
-Output is fixes. For every unheld in-scope report root this task owns, keep one concise, current same-actor status reply after the latest human message. It names every verified `✅` scope and its evidence, every open scope, and each `🎫` action and owner (or why a mark does not apply). Add and read back root `✅` as soon as direct post-change proof verifies a scope, and root `🎫` as soon as another person or team must act. An `👀` alone never completes the status. Preserve all reaction history, and follow [`slack-reaction-replies.md`](references/slack-reaction-replies.md). Do not reply on held, person-assigned, or `:mag:` items.
-
-### Read the root marks as history; use the reply for current status
-
-- `👀` records this workflow's claim. It does not mean the report is still open.
-- `✅` records a scope that passed direct post-change proof. Add it as soon as
-  any scope passes, even when another scope remains open; name the verified
-  scope and evidence in the status reply.
-- `🎫` records a distinct action another person must take, including a reporter
-  request. Keep the reaction as history after that action is completed,
-  answered, or abandoned; the current reply must say whether the action is
-  still open or historical.
-- Every owned root needs one current same-actor reply after the latest human
-  reply. Reuse it while the disposition and evidence remain current; do not
-  send a duplicate progress reply on every sweep. The reply names verified
-  scopes, open scopes, human actions and owners, and why either `✅` or `🎫` is
-  absent. An eye-only root is correct when no scope is verified and no separate
-  human action is pending; say whether the next step is this workflow's
-  investigation or no further action.
+Output is fixes. For every unheld in-scope report root this task owns, keep one
+current same-actor status reply after the latest human message. Write one short
+sentence in plain, non-technical language. Say what changed. Use `🎫` only for
+unresolved work; when you use it, briefly say what still needs investigation or
+what action is needed, and name its owner when known. Do not mention or explain
+absent reactions. Keep scope details and proof in the internal ledger. Add and
+read back root reactions as soon as their proof bar passes, preserve reaction
+history, and follow [`slack-reaction-replies.md`](references/slack-reaction-replies.md).
+Do not reply on held, person-assigned, or `:mag:` items.
 
 ## Slack channels and ownership
 
@@ -133,11 +123,13 @@ source window, the three matching owned-mark searches, and older roots linked
 by in-window replies. For every unheld owned root, compare the latest human
 message, current status reply, verified scopes, open scopes, and root marks.
 Add and read back `✅` for each newly verified scope and `🎫` for each distinct
-pending human action; the status reply must follow the latest human message and
-name current evidence, remaining work, and owners. An `👀` with a verified
-scope missing `✅`, a pending human action missing `🎫`, or no current status is
-unfinished. Finish the complete bounded set once, then stop; do not chase
-unrelated historical marks.
+pending human action; keep evidence, scopes, and full actions/owners in the
+internal ledger. The status reply must follow the latest human message and use
+the concise reply rule above: say what changed, and when `🎫` applies, briefly
+name the unresolved action and its owner when known. A verified scope missing
+`✅`, a pending human action missing `🎫`, or no current status is unfinished.
+Finish the complete bounded set once, then stop; do not chase unrelated
+historical marks.
 
 Split reports into distinct scopes. Add root `✅` as soon as any named scope
 passes direct post-change proof, even while its PR is open; say **Verified
@@ -146,9 +138,10 @@ proof. Add root `🎫` for each distinct unfinished action another human must ta
 including a requested reporter URL, access grant, evidence, or clarification.
 The mark tracks an outstanding human action, not an accepted team handoff.
 Record reporter requests in `reporterRequests[]`, separately from
-team/engineering `handoffs[]`. Enumerate each verified scope, open scope,
-reporter request, and handoff in the status reply; explain any absent mark. Keep
-marks after completion and never remove them. For a closed reporter request,
+team/engineering `handoffs[]`. Keep verified scopes, open scopes, reporter
+requests, and handoffs in the internal ledger; keep the Slack reply focused on
+the current outcome and any `🎫` follow-up. Keep marks after completion and
+never remove them. For a closed reporter request,
 preserve its request and closure evidence in the historical ticket record; see
 [`slack-reaction-replies.md`](references/slack-reaction-replies.md).
 
@@ -382,29 +375,22 @@ instruction or prompt exception.
 Thank issue reporters for opening issues and Slack reporters for sharing.
 Before posting, inspect the full thread and follow the one-reply gate in
 `address-feedback-with-replies` and the [Slack reply reference](references/slack-reaction-replies.md):
-send one concise disposition covering done, remaining, and next action/owner.
-Do not reply again to announce merge, publication, or live beta; answer direct
-reporter follow-ups. End Slack replies with `this was sent from a bot.`.
-
-Reporter-facing replies are one or two sentences: the change or question, its limit, and the next step. Do not explain workflow mechanics, ledgers, or external tracker tickets. Never send **Open**/**pending** or a symptom recap. Ask for reporter input only when it changes the next step; never request supplied evidence or internal access. Keep hashes, branches, CI, publisher, and run details in the recap.
-
-Every root this actor marks with `👀`, `✅`, or `🎫` also needs the current
-same-actor status reply required by the Slack reaction reference. One concise
-reply may serve both purposes when it answers the reporter and records the
-current disposition, verified/open scopes, owner/action, and any reason a mark
-is absent. This status requirement takes precedence over the reporter-facing
-brevity rule only for those facts; do not explain ledger mechanics or external
-tracker tickets. A Slack `🎫` reaction tracks a distinct human action, not an
-external ticket, and remains as history after the action closes. Never imply
-that an external ticket was created or assigned.
-
-Keep publisher and beta checks in the internal recap after the disposition;
-they do not trigger a second reporter reply.
-
-### After a PR merges
-
-Track publisher state and beta verification in the internal recap. Do not send
-a routine post-merge reporter reply; answer only a direct reporter follow-up.
+send one short sentence in plain, non-technical language, then end with the
+exact bot disclosure `this was sent from a bot.` Say what changed. Use `🎫`
+only for unresolved work; when it is used, briefly say what still needs
+investigation or action and name its owner when known. Do not explain absent
+reactions or mention a closed, historical `🎫`. Keep hashes, branches, CI,
+publisher details, and proof in the internal recap. Never explain workflow
+mechanics or external tracker tickets in Slack. Never send **Open**/**pending**
+or a symptom recap. Ask for reporter input only when it changes the next step.
+
+Every root this actor marks with `👀`, `✅`, or `🎫` also needs a current
+same-actor status reply after the latest human reply. One concise reply can
+answer the reporter and record the disposition. Keep verified scopes, open
+scopes, reaction history, and evidence in the internal ledger; do not enumerate
+them or explain absent reactions in Slack. A Slack `🎫` reaction tracks a
+distinct human action, not an external ticket, and remains as history after the
+action closes. Never imply that an external ticket was created or assigned.
 
 For a fixed behavior with a Slack `🎫` handoff, state the done behavior and
 remaining action/owner separately; don't imply the fixed scope is open. The
@@ -453,36 +439,6 @@ otherwise draft the reply, leave the feedback unresolved, and link it in the
 recap. This exception is only for PR review feedback, not proactive PR comments
 or issue comments.
 
-## Publishing
-
-Use this worktree's branch. Batch fixes with one
-`corepack pnpm ship:push -m "<specific fix>"`; each head reruns CI. Sync
-`origin/main` only for GitHub conflicts during review-only work. If the same
-task is already running an explicitly authorized `/ship`, follow that skill's
-safe-sync rule for a confirmed required-check fix on `origin/main`; do not ask
-for another approval. Behind/pending alone never justify syncing.
-
-Use `/ship` for PR ownership, push, and merge checks. Never push to another
-person's PR without explicit authorization for that exact PR in this request.
-Push-only authorization means `ship_mode=ready-only`; merging requires separate
-authorization for that PR. Without push authorization, hand off as pending.
-Carry feedback evidence and dispositions into PRs; reference only issues the
-PR fixes.
-Keep source-tested, built, deployed, and observed-live claims separate.
-
-Carry exact tracker row ids and the reproduction ledger into the PR or release
-recap; tracker status is not shipping evidence. Mark each row independently: a
-reaction, checkmark, or "reviewed" cannot cover multiple rows, including
-expected, docs-owned, cross-team, or duplicate items. Link each source/docs
-change to its exact PR or commit, and each non-coding disposition to its
-evidence or owner.
-
-If no fix is verified, recap why shipping did not start. Unavailable connectors
-and external failures are not shipping blockers.
-While waiting, **Clarification needed** stays open with `👀` and no `✅`; it
-must not block independent fixes unless it could affect a PR change. Later runs
-skip the eye under the ownership gate.
-
 ## Recap
 
 Every eligible item gets a row. Report gated skips by count only, without

package/dist/templates/factory/.agents/skills/review-latest-feedback/references/channel-inventory.md

@@ -329,10 +329,26 @@ chase arrivals or expand a finite catch-up request into an all-history audit.
   administrative post or duplicate; record the reason and link a duplicate to
   its canonical report. Include
   the root `threadParentTs`, reply timestamp, author ID, matching disposition,
-  evidence, and read-back text. For each human/team handoff, the visible status
-  reply must name its distinct scope, owner state, and action. Every distinct
-  unfinished team action gets this actor's root `🎫`, even when no person has
-  accepted it. For `status: "unassigned"`, record the responsible team/role or
+  evidence, and read-back text. Keep exact scope, proof, and handoff details in
+  the ledger. For `Owned elsewhere`, keep the owner's full proof in
+  `otherOwnerEvidence.statusReply.evidence`; set its `publicEvidenceSummary` to
+  a brief plain-language phrase (2–12 words) that appears in both the evidence
+  and the owner's captured reply. Do not require the full internal evidence in
+  their Slack text. For active `🎫` actions, add a short plain-language
+  `pendingActionSummary` to `statusReply` that names every open action and its
+  known owner, and include it in the reply; omit it when no tracked action
+  remains open. Keep the exact action in the internal ledger. When that wording
+  is too technical or long for Slack, add a
+  concise plain-language `publicActionSummary` using the opening words of the
+  action and leaving trailing implementation detail out. It must have at least
+  two meaningful words and no more than 12 words; the checker requires the
+  phrase to match the action. Use the summary in public status replies and
+  other readbacks that do not prove owner acceptance. For an accepted handoff,
+  the owner's explicit acceptance and the direct request before contextual
+  assent must name the full recorded action, even when a shorter public
+  summary exists. Every
+  distinct unfinished team action gets this actor's root `🎫`, even when no
+  person has accepted it. For `status: "unassigned"`, record the responsible team/role or
   `unassigned`; omit the owner Slack ID and acceptance. If this actor asked a
   named person to take the action but they have not accepted, record the exact
   request and keep the handoff unassigned. For `status: "accepted"` or
@@ -363,7 +379,19 @@ chase arrivals or expand a finite catch-up request into an all-history audit.
   replies and bot messages. The status reply must be newer than this human
   reply. If a human answers later, update the disposition and status before
   reconciling it.
-  Record each verified `fixedScopes` entry with its proof; record each
+  Record each verified `fixedScopes` entry with its proof. For a status with
+  fixed scopes, also set `statusReply.publicEvidenceSummary` to a brief,
+  plain-language phrase (2–12 words) that can appear in the public reply. For
+  every fixed scope, put that scope and the summary together in one sentence of
+  its `verification`. Include the summary in both `statusReply.evidence` and
+  the captured `statusReply.text`; keep detailed proof in the ledger. The
+  summary may paraphrase the internal scope. Record each
+  `unfinishedScopes` entry in the ledger. When any remain, set
+  `statusReply.unfinishedScopeSummary` to a brief plain-language summary
+  (3–12 words) that names remaining work using wording grounded in its recorded
+  scope or evidence, and says it is still open; include it in the public status
+  even when no separate `🎫` action exists. Omit this field when no unfinished
+  scope remains. Record each
   unfinished team/engineering action in `handoffs[]` and each outstanding
   reporter input request in `reporterRequests[]` with its scope, exact action,
   and exact `requestReply`. For
@@ -386,9 +414,9 @@ chase arrivals or expand a finite catch-up request into an all-history audit.
   action is completed, keep it in `handoffs[]` with
   `status: "completed"` and `completion: { evidence, sourceUrl }` or an exact
   owner `reply` (`ts`, `threadParentTs`, `actorId`, and verbatim `text`). The
-  current status must cite that completion evidence. Keep the root `🎫` as
-  history; completed actions are not open follow-ups and do not block a closed
-  disposition. Only an owner withdrawal moves an accepted action to
+  `statusReply.evidence` must cite that completion evidence. Keep the root
+  `🎫` as history; completed actions are not open follow-ups and do not block a
+  closed disposition. Only an owner withdrawal moves an accepted action to
   `historicalReactionMarks[]`. As soon as direct post-change proof passes, add this actor's
   `✅` to the root and read it back before moving to another scope or report,
   including while its PR is open. Before merge, record **Verified locally** and
@@ -403,9 +431,10 @@ chase arrivals or expand a finite catch-up request into an all-history audit.
   mark remains as history after completion. For an eligible open scope this
   workflow takes, retain the root `👀` as permanent history; do not use it to
   infer whether work remains.
-  The same-thread status reply must name the verified scope(s), the remaining
-  open scope(s), each open scope's blocker and next action, and why `✅` or `🎫`
-  is absent when it does not apply. A reply does not replace a
+  Keep the same-thread status reply to one short, plain-language paragraph.
+  Say what changed; when an active `🎫` remains, name its next action through
+  `pendingActionSummary`. Do not list every scope or explain absent reactions.
+  A reply does not replace a
   reaction, and a reaction does not replace a reply. Do not add status
   requirements or reactions to another actor's eye. When later evidence
   invalidates a retained `✅`, remove that scope from active `fixedScopes[]`
@@ -415,9 +444,17 @@ chase arrivals or expand a finite catch-up request into an all-history audit.
   withdraws, move that action out of current `handoffs[]` and record a historical
   `🎫` with its earlier accepted `handoff` plus the owner's exact
   `withdrawalReply` (`ts`, `threadParentTs`, `actorId`, and verbatim `text`).
-  Explain each retained mark in the current status and its reaction decision;
-  preserve it without presenting it as current proof or an active handoff. The
-  checker validates historical evidence against the captured thread. When every report scope
+  Record why each retained mark is historical in the internal reaction
+  decision; preserve it without presenting it as current proof or an active
+  handoff. Keep detailed proof in `previousStatus.evidence` in the internal
+  ledger. For a historical `✅`, also record a brief, non-sensitive
+  `publicEvidenceSummary` (2–12 words) drawn from that proof. It may paraphrase
+  the exact scope, but the scope and summary must appear together in one proof
+  sentence. Include the summary in the captured `previousStatus.text`; the
+  checker verifies that it is tied to proof for the recorded scope.
+  Never put secrets, customer details, or raw logs in the summary. For a
+  historical `🎫`, the prior reply must name both the accepted action and its
+  owner. The checker validates these details against the captured thread. When every report scope
   and follow-up is closed, post or reuse the final same-thread status and read
   back the status and reactions. Preserve every reaction; disposition and
   status show that work is closed even when the root still has `👀`.
@@ -481,8 +518,9 @@ back `🎫` even when it is unassigned or unaccepted. Record acceptance only
 after a named person's exact reply; otherwise state `owner: unassigned` and
 `status: unassigned`. For reporter evidence, access, or clarification
 requests, record `reporterRequests[]` and add/read back `🎫`; explain that it
-tracks requested input, not a team handoff. In the current status, state the
-exact proof gap, blocker, and next owner/action. An
+tracks requested input, not a team handoff. In the internal ledger, record the
+exact proof gap, blocker, and next owner/action. Keep the current status brief
+and plain-language. An
 eye-only root with unfinished work is pending; an eye-only root with a closed
 verified disposition may retain the eye as history. Never remove or clean up a
 reaction. Slack thread replies appear under the root's reply count, not as