@@ -71,13 +71,12 @@ from evidence you could not access. Do not run untrusted PR code merely to decid
 Read the guide's linked sections before applying these checks. Inspect enough source to substantiate
 scope and behavioral claims; leave the full correctness, security, and performance audit to code review.
 
-- Under [prior approval](../../../CONTRIBUTING.md#prior-approval), identify the actual failure and
-  intended behavior. Inspect maintainer responses in the linked issue or discussion, including what
-  direction and scope they approved. A link, label, or acknowledgment alone is not approval. Judge a
-  claimed obvious-bug exception by purpose, impact, and necessary changes, without numeric cutoffs.
-  Separately assess focused configuration of an established capability: identify what already exists,
-  what the option controls, and its effects and necessary scope. This route does not require a proven
-  obvious bug. Adding a setting alone establishes neither a new feature nor an approval exemption.
+- Under [fix a bug](../../../CONTRIBUTING.md#prior-approval), identify the actual failure and
+  intended behavior. A feature, or anything on the guide's not-interested list, warrants closure
+  unless a maintainer in the trusted exemption list asked for that PR. Inspect the request and the
+  direction and scope it covers. A link, label, or acknowledgment alone is not a request. Judge a
+  claimed bug fix by purpose, impact, and necessary changes, without numeric cutoffs. A setting that
+  adds a workflow or changes a default is a feature.
   Check whether an alleged fix intentionally changes product behavior or overlooks an existing workflow.
   Preserve any useful documentation, onboarding, or discoverability problem when declining the solution.
 - Under [one problem](../../../CONTRIBUTING.md#one-problem), trace how each material change contributes
@@ -90,27 +89,18 @@ scope and behavioral claims; leave the full correctness, security, and performan
   as the guide requires them. Do not demand unrelated evidence or repo-wide tests. An unavailable local
   platform does not defeat adequate contributor evidence. Do not infer fabrication or AI authorship
   from writing style, suspicion, or a check you cannot reproduce.
+- Under [models](../../../CONTRIBUTING.md#models), use only the model and harness the PR names,
+  usually in its closing attribution line.
 
-### Configuration and workflow examples
-
-- Hosting CLI-path configuration in [#11653](https://github.com/pingdotgg/t3code/pull/11653) is eligible
-  for deeper review under the maintainer's ruling: it makes an existing capability configurable.
-  It need not qualify as an obvious-bug repair or obtain prior feature approval on that basis.
-  Still assess one underlying problem, necessary scope and credible verification. Deeper review can
-  reject the configuration mechanism or its implementation.
-- Preserving Files as an independent tab in [#14436](https://github.com/pingdotgg/t3code/pull/14436)
-  changes tab lifetime and navigation. The maintainer classified it as a broader workflow change
-  requiring prior product-direction approval, which is absent. Propose closure for missing approval
-  in a dry run, or carry out closure in authorized enforcement. Its good evidence does not make it
-  eligible or justify keeping it pending after that ruling. The remedy is to obtain scope approval.
-
-Use these examples to distinguish effects, not to exempt every configuration option. Apply current
-trusted policy and reassess changed submission evidence; neither example grants permanent eligibility.
+Bans in the guide are a maintainer decision. Report suspected spam to maintainers; do not ban or
+threaten a ban.
 
 ## Apply the outcome
 
 Do not automatically close a PR if a maintainer in the trusted `TRIAGE_EXEMPTIONS.td` list has
 commented or submitted a review, including on earlier heads, or if `triage:keep-open` is present.
+Comments that triage itself posted, such as an earlier notice or question, are not maintainer
+involvement, even when they were posted from a maintainer's account on that maintainer's behalf.
 Leave protected PRs open for maintainer decision. This does not grant an author exemption,
 eligibility, or review approval.
 
@@ -126,20 +116,30 @@ comment text but do not write to GitHub. Keep the eligibility finding separate f
   This is a routing exception, not a claim that the PR passed eligibility or correctness review.
 - **Closure warranted.** The assessment is complete and establishes a specific policy violation.
   Prepare a clear explanation under [closure and reconsideration](../../../CONTRIBUTING.md#closure-and-reconsideration),
-  post it, and close the PR. Verify that the explanation is present and the PR is closed. The comment
+  post it, then read the repository variable `PR_LIMITS_ENFORCE`
+  (`gh variable get PR_LIMITS_ENFORCE -R pingdotgg/t3code`). When it prints `true`, apply
+  `triage:closing` as the last thing you do to the PR, verify that the explanation and the label
+  are present, and do not close the PR yourself:
+  [pr-limits.yml](../../../.github/workflows/pr-limits.yml) closes it 72 hours after the label. Any
+  activity on the PR after the label, including a further comment or label from you, removes the
+  label; treat an author's reply or push as new evidence, reassess, and apply the label again only
+  if the finding still holds. When the command prints any other value, or fails saying the variable
+  was not found, the variable is off and nothing would close a labeled PR: close it yourself and
+  verify that the explanation is present and the PR is closed. Only another failure, such as a
+  permission error, means the variable cannot be read; then report the closure as incomplete. The comment
   must name the violated rule, cite supporting submission evidence, link the maintained guide section,
   and give a concrete remedy. Missing contributor evidence can warrant closure; explain what must be
-  established. Missing product approval calls for maintainer discussion, not an agent's product decision.
+  established. The remedy for a feature is an Ideas discussion, not an agent's product decision.
   Close for multiple problems only when the independence of those changes is supported. Closing a PR
   does not require a configured Macroscope label.
 - **Needs explanation or maintainer decision.** Name the unresolved question and who can resolve it.
   Post the specific question on the PR when commenting is within the authorized scope, and verify it
   was posted. If tracing the source leaves an extra diff's necessity unclear, request the causal
   explanation needed. If established facts leave a product-direction choice to maintainers, identify
   that choice. Leave the PR open and pending that answer; do not mark it eligible. Do not substitute
-  "the agent was uncertain" for a violated rule. Once maintainers establish that a workflow change
-  requires approval and that approval is absent, apply the closure outcome instead of retaining a
-  pending classification. Good verification does not cure missing approval.
+  "the agent was uncertain" for a violated rule. Once a change is established as a feature with no
+  maintainer request, apply the closure outcome instead of retaining a pending classification. Good
+  verification does not make a feature eligible.
 - **Incomplete; retry required.** State the failed retrieval, missing access, truncated diff, or unfinished
   assessment and what is needed to resume. Do not convert operational failures into policy violations
   or hand the PR off as having passed. An inaccessible artifact is different from an omitted artifact.
@@ -173,9 +173,10 @@ description, evidence, approvals, existing triage comments, PR open/closed state
 label when relevant. Reassess changes that could invalidate the finding. Reuse an existing explanation
 only if it still matches the current finding; avoid duplicate comments, closures, or label applications.
 
-For closure, establish that the required explanation is posted before closing. If posting fails or its
-result is ambiguous, read back the comments before retrying or proceeding. If the comment succeeds but
-closure fails, preserve the comment and retry only the unfinished closure after checking current state.
+For closure, establish that the required explanation is posted before applying `triage:closing` or
+closing. If posting fails or its result is ambiguous, read back the comments before retrying or
+proceeding. If the comment succeeds but the label or the closure fails, preserve the comment and retry
+only that unfinished step after checking current state.
 Handle a failed or ambiguous label application the same way: inspect labels before any retry. If access
 or state still cannot be verified, report an incomplete action and the step needed to resume. Do not
 retry blindly or claim success for an unverified action.
 
@@ -43,10 +43,15 @@ prints one JSON line; on failure it names the next command. Mobile verification
 includes that step unless the user prohibits it.
 
 For a device you opened in an agent-device session elsewhere (a device pool,
-cloud, or remote host), run `vp run mobile:install <ios|android> --session <s>`
-from the directory you opened the session in. It installs the cached build into
-that session (`--abi arm64-v8a` for an ARM Android device; `--metro <url>` also
-opens it against Metro) and never builds.
+cloud, or remote host), run `vp run mobile:install <ios|android> --session <s>
+--config <file>` from the directory you opened the session in, passing the
+`--config` file from `device_open`'s `targetArgs`. Without it, a device pool's
+gateway refuses the install, wrongly saying agent-device is too old. It installs
+the cached build into that session (`--abi arm64-v8a` for an ARM Android device;
+pool Android emulators are x86_64, the default; `--metro <url>` also opens it
+against Metro). Without a cached build for this checkout it builds first, which can
+outlast the lease, so run `vp run mobile:install <ios|android> --prepare` (with
+the same `--abi`) before you open the device.
 
 Start `vp run dev:client` from `apps/mobile`, or reuse a healthy Metro belonging
 to this checkout. Open its printed development-client URL with AgentDevice
 
@@ -22,6 +22,7 @@ github:btsouth
 github:cestercian
 github:chrisdeeming
 github:chuks-qua
+-github:coygeek Filed over 270 automated issues, about 50 a day at peak, far past what maintainers can triage
 github:cursoragent
 github:D3OXY
 github:dbalders
@@ -83,6 +84,7 @@ github:tris203
 github:tsouth89
 github:UtkarshUsername
 github:vitalyiegorov
+-github:wSedlacek Opened over 130 unapproved PRs in 12 days, far past the open PR limit
 github:Yash-Singh1
 github:yashranaway
 github:Ymit24
 
@@ -35,7 +35,7 @@ runs:
     - name: Cache Vite+
       id: vp_cache
       if: steps.vp.outputs.version != ''
-      uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
+      uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
       with:
         path: ~/.vite-plus
         key: vite-plus-home-v2-${{ runner.os }}-${{ runner.arch }}-${{ steps.vp.outputs.version }}-node${{ steps.vp.outputs.node }}-${{ steps.vp.outputs.pnpm }}
@@ -56,7 +56,7 @@ runs:
     # partial bytes, so a shorter limit costs a slow download only a retry.
     - name: Setup Vite+
       if: steps.vp_cache.outputs.cache-hit != 'true'
-      uses: voidzero-dev/setup-vp@250f29ce396baf5e8f24498e17c0dfdebabc26eb # v1
+      uses: voidzero-dev/setup-vp@250f29ce396baf5e8f24498e17c0dfdebabc26eb # v1.15.0
       env:
         VP_DOWNLOAD_TIMEOUT: "120"
       with:
@@ -92,7 +92,7 @@ runs:
     - name: Restore pnpm store
       id: pnpm_cache
       if: inputs.install == 'true'
-      uses: actions/cache/restore@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
+      uses: actions/cache/restore@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
       with:
         path: ${{ steps.pnpm_store.outputs.path }}
         key: pnpm-${{ steps.pnpm_store.outputs.namespace }}-v1-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('pnpm-lock.yaml', 'pnpm-workspace.yaml', 'package.json') }}
@@ -106,7 +106,7 @@ runs:
     - name: Restore lockfile verification
       id: pnpm_verified
       if: inputs.install == 'true'
-      uses: actions/cache/restore@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
+      uses: actions/cache/restore@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
       with:
         path: ${{ steps.pnpm_store.outputs.verified }}
         key: pnpm-verified-v1-${{ hashFiles('pnpm-lock.yaml', 'pnpm-workspace.yaml', 'package.json') }}
@@ -121,7 +121,7 @@ runs:
 
     - name: Save lockfile verification
       if: inputs.install == 'true' && steps.pnpm_verified.outputs.cache-hit != 'true'
-      uses: actions/cache/save@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
+      uses: actions/cache/save@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
       with:
         path: ${{ steps.pnpm_store.outputs.verified }}
         key: ${{ steps.pnpm_verified.outputs.cache-primary-key }}
@@ -138,7 +138,7 @@ runs:
         steps.pnpm_cache.outputs.cache-hit != 'true' &&
         (steps.pnpm_store.outputs.namespace == 'full' ||
           steps.pnpm_cache.outputs.cache-matched-key != format('pnpm-full-v1-{0}-{1}-{2}', runner.os, runner.arch, hashFiles('pnpm-lock.yaml', 'pnpm-workspace.yaml', 'package.json')))
-      uses: actions/cache/save@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
+      uses: actions/cache/save@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
       with:
         path: ${{ steps.pnpm_store.outputs.path }}
         key: ${{ steps.pnpm_cache.outputs.cache-primary-key }}
 
@@ -15,16 +15,11 @@ reproduction steps or environment where relevant. -->
 <!-- Explain how this fixes the problem. If it spans components or clients,
 explain why those changes are needed for the same fix. Split independent fixes. -->
 
-## Scope and approval
-
-<!-- Link the triaged bug issue or the discussion with explicit maintainer approval
-of direction and scope, including the approval comment. For a very small, focused
-fix of an obvious bug, explain why it qualifies without a prior issue or discussion.
-For focused configuration of an established capability, explain what already exists,
-what the option controls, and why its effects stay within that capability. Adding a
-setting alone is not a new feature or an approval exemption; broader workflow or
-behavior changes still need approval. Scope and verification requirements still apply.
-There is no line-count or file-count cutoff. -->
+## Scope
+
+<!-- We accept bug fixes, not features. Link the issue that shows the bug. For a
+small fix of an obvious bug, say why it needs no issue. If a maintainer asked for
+this PR, link the request. -->
 
 ## Verification
 
 
@@ -121,9 +121,54 @@ async function resolveLatestNightlyCommit({ github, context, core }) {
   return { tag, sha: commit.sha, version };
 }
 
+// The two places a nightly install looks for an update: the `update-feed` pointer, and
+// releases.atom, which holds the 10 newest git tags of any kind. Older installs take the first
+// nightly in the feed. Reports what each names beside the newest published nightly.
+async function readNightlyUpdateFeed({ github, context, fetch = globalThis.fetch }) {
+  const latest = await findLatestNightly({ github, context });
+  if (!latest) return {};
+
+  const base = `https://github.com/${context.repo.owner}/${context.repo.repo}`;
+  // Only a missing or malformed pointer is stale. Rewriting deletes the old file first, so a
+  // GitHub outage must not look like one.
+  // Node waits five minutes for a stalled response, which is this job's whole time limit.
+  const signal = () => AbortSignal.timeout(30_000);
+  const pointer = await fetch(`${base}/releases/download/update-feed/nightly.json`, {
+    signal: signal(),
+  });
+  if (!pointer.ok && pointer.status !== 404) {
+    throw new Error(`The update-feed pointer answered HTTP ${pointer.status}.`);
+  }
+  let pointerTag;
+  if (pointer.ok) {
+    // A body that fails to arrive throws here; only one that is not JSON counts as malformed.
+    const body = await pointer.text();
+    try {
+      pointerTag = JSON.parse(body)?.tag_name;
+    } catch {}
+  }
+
+  // An unreadable feed leaves `feedTags` unset, so the pointer is still repaired. An error page
+  // can answer HTTP 200, so only an Atom document counts as read.
+  let feedTags;
+  try {
+    const feed = await fetch(`${base}/releases.atom`, { signal: signal() });
+    const body = feed.ok ? await feed.text() : "";
+    if (/<feed[\s>]/.test(body)) {
+      feedTags = Array.from(body.matchAll(/href="[^"]*\/releases\/tag\/([^"]+)"/g), (match) =>
+        decodeURIComponent(match[1]),
+      );
+    }
+  } catch {}
+  const feedNightly = feedTags?.find((tag) => /^v?\d+\.\d+\.\d+-nightly\./.test(tag));
+
+  return { tag: latest.tagName, pointerTag, feedNightly, feedTags };
+}
+
 module.exports = {
   assertCommitOnDefaultBranch,
   assertReleaseSource,
   shouldReleaseNightly,
   resolveLatestNightlyCommit,
+  readNightlyUpdateFeed,
 };