@agent-native/core 0.213.1 → 0.216.0

package/src/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/src/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/src/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

package/src/templates/factory/.agents/skills/review-latest-feedback/references/slack-reaction-replies.md

@@ -13,53 +13,35 @@ record as history; the root remains held without a thread read or status reply.
 Capture
 the exact Slack actor ID used by the connected tool at sweep start. A mark is
 owned by this task only when its reaction owner ID matches that actor ID. Each
-unheld owned root needs a current disposition and a matching status reply by
-that same actor under that same parent, even when the root has only `✅` or `🎫`. A
-same-run fix gets its final reply after verification; continuing work gets a
-concrete progress reply. An earlier generic “taking a look” does not satisfy
-this update. If an existing reply already names the exact canonical disposition
-label and includes its recorded evidence verbatim, read it back and record its
-timestamp and author ID instead of duplicating it. Do not accept a vague or
-negated substring such as `Not fixed` as the `Fixed` label; reject the whole
-reply if a `Fixed` label is later contradicted by a claim that the scope remains
-not fixed, unfixed, or broken. Use `Partially fixed` while any distinct scope
-remains unfinished or a human/team handoff is still `unassigned` or `accepted`.
-A completed handoff is retained history, not an open follow-up.
-This is one current status reply per owned root, not a reply on every sweep.
-Reuse the existing same-actor reply while its disposition and evidence remain
-current; send an update when either materially changes. For a recent
-unanswered reporter question, reuse the existing same-actor question/update as
-the status reply when it states the disposition and evidence. If it does not,
-post at most one concise status update that points to the existing unanswered
-question without asking it again; then wait silently. Do not send another
-question or progress ping before the four-day rule below. When a disposition
-includes human handoffs, the status reply must name each handoff's recorded
-owner and action; include its scope when the report context does not make it
-clear.
+unheld owned root needs a current same-actor status reply under the same parent.
+Reuse it while the disposition remains current; send one short update when it
+materially changes. Write 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 scope, evidence, and handoff details in the internal
+ledger.
 
-Interpret the three root reactions independently from the current disposition:
+Do not send a routine second reply just to announce a merge or publication.
 
-- `👀` is a permanent claim/history mark, not an open/closed indicator.
-- `✅` is permanent history for named scopes that passed direct post-change
-  proof. Add it as soon as any scope passes; do not wait for other scopes or
-  merge. Keep it if later evidence changes the scope's status, and explain the
-  historical mark in the current reply and inventory.
-- `🎫` is permanent history for a distinct human action, including an
-  unassigned team action or reporter request. Keep it after completion,
-  answer, or four-day abandonment; label it historical in the current reply
-  and inventory when it no longer blocks progress.
+For a recent unanswered reporter question, reuse the existing same-actor
+question/update as the status reply when it still reflects the disposition. If
+it does not, post at most one concise update that points to the question
+without asking it again; then wait silently. Do not send another question or
+progress ping before the four-day rule below. An evidence-only addendum or
+correction is not a current status; edit it into a concise disposition when
+possible, or send one status after the latest human reply.
 
-The current status reply is the source for whether work remains open. When a
-root has only `👀`, say that no scope has passed the proof bar for `✅`, whether
-the next step belongs to this workflow, and why no separate human action needs
-`🎫`. Reuse a current reply rather than posting again on every sweep.
-
-An evidence-only addendum or a correction is not a current status. When your
-newest own reply is one of those, edit that reply into the full canonical
-disposition when possible; otherwise send one final status after the latest
-human reply. Name the verified `✅` scope or why none applies, every open scope,
-and each `🎫` action with its owner or why none applies. Keep the exact bot
-disclosure and read the visible final reply and root reactions back.
+Keep full proof, scope, and handoff details in the internal ledger. When an
+active `🎫` action remains, record its brief plain-language summary as
+`statusReply.pendingActionSummary` and include that summary in the short reply.
+When `unfinishedScopes` is nonempty, also record a brief
+`statusReply.unfinishedScopeSummary` that names remaining work using wording
+grounded in its recorded scope or evidence and says it is still open; include it
+in the public reply even when there is no active `🎫`.
+Do not explain absent reactions or list every scope. End with the exact bot
+disclosure and read the visible reply and root reactions back.
 
 When editing an ordinary Slack reply, pass its visible body as
 `message.markdown_text` to `slack_edit_message`; `message.text` is a fallback
@@ -166,7 +148,8 @@ then immediately update and read back each applicable root reaction before
 advancing to the next report. Add `✅` as soon as any reported scope passes the
 direct post-change proof bar, including before merge; use
 **Partially fixed** for the overall disposition when another scope remains,
-and describe both scopes separately in the reply. Do not wait for an entire
+and record both scopes in the internal ledger. Keep the reply short; do not
+wait for an entire
 multi-symptom report to be resolved before checking off its verified scope.
 Keep all existing reactions after scopes close. Post the final disposition and
 read back the final reply and reactions; the status shows closure while the
@@ -174,7 +157,7 @@ eye remains as history. Never remove or clean up any reaction. An open PR can
 earn `✅` as soon as the relevant
 `verifying-changes` proof bar passes. During that period, `✅` marks the
 verified scope and `👀` may remain whether or not another scope or merge is
-open; the marks are independent. The current disposition says what remains.
+open; the marks are independent. The internal ledger records what remains.
 For UI behavior, a focused
 regression qualifies only if it exercises the changed component and asserts the
 reported visible result or persisted state; callback-only assertions, mocked
@@ -182,24 +165,28 @@ children, class-name checks, and source inspection do not. For clipping,
 wrapping, contrast, or alignment, inspect rendered geometry at the reported
 viewport or replay the flow in the running app. Use an app/preview replay when
 the regression does not meet that bar. For non-UI scopes, use the area-specific
-action, query, or test proof. Say that merge or rollout is still pending; the
-checkmark records the verified scope and does not claim it is shipped or live.
+action, query, or test proof. Record merge or rollout state in the internal
+ledger; the checkmark records verified scope and does not claim it is shipped
+or live.
 Before leaving each report, compare verified scopes and human/team handoffs
 with a fresh root-reaction read. Ensure one `✅` is present when any scope passed the
 proof bar and one `🎫` whenever any distinct unfinished action requires another
 person or team to act, even before ownership is assigned or accepted. Keep the
 mark as history after completion; read back each changed root reaction and
-verify its owner. If either mark does
-not apply, the current reply must say why. Emoji text in a reply is not a
+verify its owner. Record why a mark is absent in the internal ledger. Never
+explain absent `👀` or `✅` in a Slack reply. Emoji text in a reply is not a
 reaction. Preserve every existing reaction. If later proof invalidates a prior
 checkmark, move that scope out of active `fixedScopes[]` and add a
 `historicalReactionMarks[]` entry with `emoji`, `scope`, `reason`, and the exact
-prior `previousStatus`; the current status and reaction decision must explain
-why the retained mark is historical. If the owner withdraws an accepted action
+prior `previousStatus`; keep the explanation in the internal ledger rather
+than the Slack reply. If the owner withdraws an accepted action
 tracked by `🎫`, also preserve the exact earlier accepted `handoff` and owner
-`withdrawalReply`, move it out of current `handoffs[]`, and explain the history
-in the current status. The checker validates these records against the captured
-thread; never remove or clean up a reaction.
+`withdrawalReply`, and move it out of current `handoffs[]`. Keep that history
+in the internal ledger. Preserve the recorded evidence and historical action in
+the ledger; do not repeat a closed handoff in Slack unless a current action
+remains. When a recorded action has a validated `publicActionSummary`, it may
+be used for a current `🎫` summary. The checker validates it against the
+recorded action and captured thread; never remove or clean up a reaction.
 Add `🎫` for each distinct unfinished team or engineering action that another
 person or team must perform outside this workflow, whether or not a named
 person has accepted it or an external tracker ticket exists. Record each such
@@ -245,8 +232,9 @@ Keep its original `scope`, `action`, `requestReply`, and ticket-bearing
 `resolution: "answered"` and include the exact human `closureReply` from the
 same thread. For an unanswered request,
 set `resolution: "abandoned_no_answer"` only after four days with no later human
-reply, and omit `closureReply`. The current status must identify the historical
-action and explain why its mark remains. Link an external tracker ticket only
+reply, and omit `closureReply`. The internal ledger must identify the
+historical action and explain why its mark remains; do not explain it in the
+Slack reply unless a current follow-up remains. Link an external tracker ticket only
 if one already exists; do not create or promise one without authorization. If a
 human later refuses the accepted action, preserve `🎫` as history and update
 the status with the refusal and blocker.
@@ -282,10 +270,11 @@ do not send a second owner update. If another task owns it or ownership is
 unclear, preserve the eye, record the source in the ledger, and stop. Keep
 distinct scopes and their status clear.
 
-Compare each reported symptom with the evidence. State what is fixed and what
-is not. Use one root `✅` when at least one fixed scope is verified; it covers every
-verified scope listed in `fixedScopes[]`, which the status must name with its
-proof. Use one root `🎫` whenever at least one distinct unfinished action
+Compare each reported symptom with the evidence. If the report is only partly
+fixed, say so briefly and keep the scope details in the ledger. Use one root
+`✅` when at least one fixed scope is verified; it covers every
+verified scope listed in `fixedScopes[]`, which the internal ledger must name
+with its proof. Use one root `🎫` whenever at least one distinct unfinished action
 requires another person to act; it covers the actions listed in `handoffs[]`
 and active requests in `reporterRequests[]`. Handoffs include unassigned
 actions and completed actions whose evidence and `status: "completed"` remain
@@ -299,18 +288,6 @@ team handoff also gets `🎫`. Do not create or promise an external tracker
 ticket without authorization. Never imply a
 partial fix resolved the whole report.
 
-For beta app fixes, check the matching merge-triggered publisher and keep
-details in the recap. Do not post a routine second reply for merge or rollout.
-If a reporter-facing reply is otherwise due, link the merged PR and state the
-beta status in plain language. Say it is live only after checking it there. If
-publication is pending, say it should follow soon without an exact date. If
-the app or behavior cannot be checked, name that limit. If the publisher is
-missing or failed, give no ETA and name the next action and owner. Keep hashes,
-branch names, CI, workflow details, and run IDs out of reporter replies. For
-package work, distinguish the source PR from any release PR and registry proof;
-source merge alone does not establish publication. Give no ETA for a pending
-package release.
-
 For every reply in each final full-thread snapshot, record a read-back of the
 workflow reactions on that reply. If the connector shows `👀`, `✅`, or `🎫`,
 call `slack_get_reactions` for the reply's own timestamp and record exact owner

package/src/templates/headless/.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/src/templates/workspace-core/.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/src/templates/workspace-core/.agents/skills/turn-into-app/SKILL.md

@@ -13,15 +13,16 @@ metadata:
 
 # Turn Into App
 
-Give a proven workflow the face of an app and the brain of an agent. The first
-screen shows the user's world, populated. Controls on those objects hand work
-to the in-app agent, the object shows it is working, and the result lands back
-in the UI. A form under a stepper bar is the failure to prevent.
+Give a proven workflow an Agent-Native app face and agent brain. Start with
+populated domain screens. Object controls send work to the agent; the object
+shows progress and receives the result. Avoid form-under-stepper layouts.
 
 ## Host, source, and when to ask
 
 ### Classify the host
 
+- Local scaffolding needs Node.js 22.22.0 or newer (including npm/npx) and
+  pnpm.
 - **Local host**: a terminal, a filesystem, and a target checkout (Claude Code,
   Codex, Cursor, or an Agent-Native agent that can edit files). Build the app in
   that checkout with steps 1-6. Never call `start-workspace-app-creation` or
@@ -105,9 +106,8 @@ opens on a mapping or setup screen.
 
 ## Workflow
 
-Copy this checklist and keep it current. Pace: aim for about 45 minutes; note
-the start time (`date`), and if 35 minutes have passed when the review starts,
-run one pass and list the open criteria.
+Copy and update this checklist. Aim for 45 minutes; note the start time
+(`date`). If review starts after 35 minutes, run one pass and list open criteria.
 
 ```text
 - [ ] 0 Host classified, source picked
@@ -160,13 +160,12 @@ without waiting.
 
 ### 3. Create the real scaffold
 
-Before the first command, say once what the run executes (install, scaffold,
-checks, a dev server, a headless browser), so permission prompts do not read
-as trouble.
+Before the first command, name the steps (install, scaffold, checks, dev server,
+headless browser) and estimate work time from the source and host. Separate
+external setup waits, so delays are expected.
 
-Choose a short slug and never overwrite an existing app. For a standalone app,
-run from the directory that should contain it (the app is its own git
-repository; say so when it sits inside another checkout):
+Choose a short slug and never overwrite an app. Run standalone creation from
+its parent directory, noting that the nested app is its own Git repository:
 
 ```bash
 npx --yes @agent-native/core@latest create <slug> --standalone --template chat
@@ -182,11 +181,10 @@ from the workspace root:
 pnpm exec agent-native add-app <slug> --template chat
 ```
 
-Read the generated `AGENTS.md`, and its `build-an-app` skill when the scaffold
-ships one. Where that guidance skips the design record, screenshots, or build,
-leaves `DESIGN.md` alone, says not to set `AUTH_DISABLED`, or says to stop the
-dev server, this skill's steps win for this run. Use another first-party
-template only when it materially fits.
+Read the generated `AGENTS.md` and any `build-an-app` skill. This skill
+overrides guidance that skips the design record, screenshots, or build; leaves
+`DESIGN.md` unchanged; omits `AUTH_DISABLED` or says not to set it; or stops
+the dev server. Use another first-party template only if it materially fits.
 
 If a scaffold or install step fails, times out (no output for 5 minutes), or is
 denied, the app does not exist yet. Retry once where a retry could help, then
@@ -195,6 +193,10 @@ hand-build the app in another stack, edit a pinned dependency version to force
 an install, or continue in a half-created directory; a workaround the user
 requests is named in the report.
 
+Before resuming, inspect the target and verify completed stages. Tell the user
+what exists, the next stage, and estimated active work; resume at the first
+unverified stage without rerunning scaffolding or replacing completed work.
+
 Then save the brief as `docs/brief.md`, append the domain surface's design to
 `DESIGN.md` (UI direction guide, section 4), and follow
 [the run and deploy guide](references/local-run-and-deploy.md) to set