fix: fix(web): equations with an unescaped percent now typeset

.agents/skills/contribution-triage/SKILL.md

@@ -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.

.agents/skills/test-t3-app/SKILL.md

@@ -5,10 +5,10 @@ description: Test T3 Code's web and desktop UI through its built-in Browser pane
 
 # Test T3 web and desktop
 
-Use T3's built-in Browser panel for verification. If its tools are absent or
-the panel reports unavailable, explain the blocker and stop verification.
-Do not install or switch to another automation system. For native mobile
-testing, use [test-t3-mobile](../test-t3-mobile/SKILL.md).
+Use T3's built-in Browser panel for verification. Follow the recovery steps
+below before declaring it unavailable. Do not install or switch to another
+automation system. For native mobile testing, use
+[test-t3-mobile](../test-t3-mobile/SKILL.md).
 
 ## Start the app
 
@@ -36,8 +36,13 @@ model, such as Haiku for Claude or Luna for Codex.
 
 ## Use the Browser panel
 
-Call `preview_status`, then `preview_open` if the Browser panel is
-closed. Navigate to the complete startup pairing URL once with
+Call `preview_status`. If no tab can be automated, call `preview_open`, including
+when status reports `available: false` or `tabId: null`. Status can report
+unavailable simply because no tab exists yet; opening a tab needs no user action.
+Stop verification and explain the blocker only if the tools are absent or
+`preview_open` reports unavailable or fails.
+
+Navigate to the complete startup pairing URL once with
 `preview_navigate`, then use `preview_snapshot` and T3's interaction tools.
 If the token was consumed or expired, run `node apps/server/src/bin.ts pair`
 for a fresh one. Keep using the same tab.

.agents/skills/test-t3-mobile/SKILL.md

@@ -36,8 +36,9 @@ vp run mobile:install <ios|android> <device-id>
 
 This installs the dev client for the checkout's native fingerprint: from the
 device, the local cache, or the shared cache in seconds, building once only
-when no machine has that fingerprint yet (5-15 minutes, logged to the file it
-names). The device id may be omitted when exactly one device is booted. It
+when no machine has that fingerprint yet: in the `Mobile Dev Client` workflow
+on Blacksmith when HEAD is pushed and `gh` may dispatch it (the command waits),
+otherwise here (5-15 minutes, logged to the file it names). The device id may be omitted when exactly one device is booted. It
 prints one JSON line; on failure it names the next command. Mobile verification
 includes that step unless the user prohibits it.
 

.github/SECURITY.md

@@ -1,7 +1,7 @@
 # Security policy
 
 Report security vulnerabilities affecting T3 Code or T3 Tools-operated infrastructure to
-[security@ping.gg](mailto:security@ping.gg). Please do not disclose them publicly until we have had
+[security@t3.codes](mailto:security@t3.codes). Please do not disclose them publicly until we have had
 a reasonable opportunity to investigate and remediate them.
 
 See the [full security policy](https://t3.codes/security-policy) for reporting details, scope,

.github/VOUCHED.td

@@ -83,6 +83,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

.github/actions/ci-changes/action.yml

@@ -5,6 +5,8 @@ outputs:
     value: ${{ steps.detect.outputs.typecheck }}
   build:
     value: ${{ steps.detect.outputs.build }}
+  desktop_launch:
+    value: ${{ steps.detect.outputs.desktop_launch }}
   test:
     value: ${{ steps.detect.outputs.test }}
   test_packages:

.github/actions/setup-ci-deps/action.yml

@@ -13,6 +13,10 @@ inputs:
     description: Arguments for `vp install`, such as filters. Empty installs the whole workspace.
     required: false
     default: ""
+  save-pnpm-store:
+    description: Set to "false" when a concurrent job with the same install args saves the pnpm store
+    required: false
+    default: "true"
 runs:
   using: composite
   steps:
@@ -123,10 +127,14 @@ runs:
         key: ${{ steps.pnpm_verified.outputs.cache-primary-key }}
 
     # A filtered install that started from the current full store adds nothing
-    # worth a second copy of it.
+    # worth a second copy of it. A stacked PR, based on a branch other than the
+    # default, saves a ~1 GB store only its own reruns can read, so it only restores.
+    # Concurrent jobs with the same install args reserve one key, so the losers
+    # compress the store for nothing; all but one pass save-pnpm-store: false.
     - name: Save pnpm store
       if: >-
-        inputs.install == 'true' &&
+        inputs.install == 'true' && inputs.save-pnpm-store == 'true' &&
+        (github.event_name != 'pull_request' || github.base_ref == github.event.repository.default_branch) &&
         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')))

.github/pull_request_template.md

@@ -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
 

.github/scripts/check-nightly-release.cjs

@@ -40,42 +40,67 @@ async function assertReleaseSource({ github, context, releaseChannel }) {
 
 const isNightlyTag = (tag) => /^v.*-nightly\./.test(tag) || tag.startsWith("nightly-v");
 
-async function findLatestNightly({ github, context }) {
-  const releases = await github.paginate(github.rest.repos.listReleases, {
-    ...context.repo,
-    per_page: 100,
-  });
-  return releases
-    .filter((release) => !release.draft && release.published_at && isNightlyTag(release.tag_name))
-    .sort((a, b) => Date.parse(b.published_at) - Date.parse(a.published_at))[0];
+// Only the three fields the gate reads. The REST list also returns every asset,
+// which made a full scan tens of megabytes.
+const RELEASES_QUERY = `
+  query ($owner: String!, $repo: String!, $cursor: String) {
+    repository(owner: $owner, name: $repo) {
+      releases(first: 100, after: $cursor, orderBy: { field: CREATED_AT, direction: DESC }) {
+        pageInfo { hasNextPage endCursor }
+        nodes { tagName isDraft publishedAt }
+      }
+    }
+  }
+`;
+
+// Returns the nightly with the newest publishedAt. Release order follows the
+// tagged commit date, not publication, so every page is read unless `isSettled`
+// says the newest nightly seen so far already decides the caller's answer.
+async function findLatestNightly({ github, context, isSettled = () => false }) {
+  let latest;
+  let cursor = null;
+  do {
+    const { repository } = await github.graphql(RELEASES_QUERY, { ...context.repo, cursor });
+    const { nodes, pageInfo } = repository.releases;
+    for (const release of nodes) {
+      if (release.isDraft || !release.publishedAt || !isNightlyTag(release.tagName)) continue;
+      if (!latest || Date.parse(release.publishedAt) > Date.parse(latest.publishedAt)) {
+        latest = release;
+      }
+    }
+    if (latest && isSettled(latest)) return latest;
+    cursor = pageInfo.hasNextPage ? pageInfo.endCursor : null;
+  } while (cursor);
+  return latest;
 }
 
 async function shouldReleaseNightly({ github, context, core, now = Date.now() }) {
-  const lastNightly = await findLatestNightly({ github, context });
+  const isInGap = (release) => now - Date.parse(release.publishedAt) < MINIMUM_RELEASE_GAP_MS;
+  // Any nightly inside the gap means the newest one is too, so stop reading.
+  const lastNightly = await findLatestNightly({ github, context, isSettled: isInGap });
 
   if (!lastNightly) {
     core.info("No published nightly found. Proceeding with release.");
     return true;
   }
 
-  if (now - Date.parse(lastNightly.published_at) < MINIMUM_RELEASE_GAP_MS) {
-    core.info(`Nightly ${lastNightly.tag_name} was published less than six hours ago. Skipping.`);
+  const tag = lastNightly.tagName;
+  if (isInGap(lastNightly)) {
+    core.info(`Nightly ${tag} was published less than six hours ago. Skipping.`);
     return false;
   }
 
   const { data: comparison } = await github.rest.repos.compareCommitsWithBasehead({
     ...context.repo,
-    basehead: `${lastNightly.tag_name}...${context.sha}`,
+    basehead: `${tag}...${context.sha}`,
     per_page: 1,
   });
   if (comparison.status !== "ahead") {
-    core.info(
-      `Candidate commit is ${comparison.status} relative to ${lastNightly.tag_name}. Skipping.`,
-    );
+    core.info(`Candidate commit is ${comparison.status} relative to ${tag}. Skipping.`);
     return false;
   }
 
-  core.info(`New commits since ${lastNightly.tag_name}, and the six-hour gap has passed.`);
+  core.info(`New commits since ${tag}, and the six-hour gap has passed.`);
   return true;
 }
 
@@ -85,7 +110,7 @@ async function resolveLatestNightlyCommit({ github, context, core }) {
     throw new Error("No published nightly found. Stable releases build the latest nightly commit.");
   }
 
-  const tag = lastNightly.tag_name;
+  const tag = lastNightly.tagName;
   const { data: commit } = await github.rest.repos.getCommit({ ...context.repo, ref: tag });
   const version = /^(?:nightly-)?v(\d+\.\d+\.\d+)-nightly\./.exec(tag)?.[1];
   if (!version) {