diff --git a/.agents/skills/contribution-triage/SKILL.md b/.agents/skills/contribution-triage/SKILL.md index 21ba3b7a6566a..e5325c398bc48 100644 --- a/.agents/skills/contribution-triage/SKILL.md +++ b/.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,10 +116,20 @@ 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. @@ -137,9 +137,9 @@ comment text but do not write to GitHub. Keep the eligibility finding separate f 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. diff --git a/.agents/skills/test-t3-mobile/SKILL.md b/.agents/skills/test-t3-mobile/SKILL.md index f48bb0377ad94..306038007e9a0 100644 --- a/.agents/skills/test-t3-mobile/SKILL.md +++ b/.agents/skills/test-t3-mobile/SKILL.md @@ -36,8 +36,9 @@ vp run mobile:install 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. diff --git a/.github/VOUCHED.td b/.github/VOUCHED.td index 1c4ae817060a9..69c1ea6575a4a 100644 --- a/.github/VOUCHED.td +++ b/.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 diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 4a66b5d268103..94157c4135fac 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -15,16 +15,11 @@ reproduction steps or environment where relevant. --> -## Scope and approval - - +## Scope + + ## Verification diff --git a/.gitignore b/.gitignore index b6b793e020ef1..85b7c5b4bf02f 100644 --- a/.gitignore +++ b/.gitignore @@ -38,6 +38,7 @@ apps/mobile/.android-cache/ artifacts/app-store/screenshots/ artifacts/mobile-e2e/ artifacts/mobile-behavior/ +scripts/.e2e/ .github/pr-assets/ native/**/target/ node_modules/ diff --git a/.macroscope/check-run-agents/ui-consistency.md b/.macroscope/check-run-agents/ui-consistency.md index 905823d1d1a9e..4326d4e8391b7 100644 --- a/.macroscope/check-run-agents/ui-consistency.md +++ b/.macroscope/check-run-agents/ui-consistency.md @@ -44,7 +44,7 @@ The reference for how this codebase wants UI built is the composer banner system - `ComposerBanner.tsx` exports one object of small slot components (`Root`, `Row`, `Icon`, `Content`, `Actions`, `Dismiss`, `Children`, and so on). Each slot owns its own Tailwind classes, exposes a `data-slot` attribute, takes `className` and spreads the rest of its props, and uses `cn` so callers can adjust without overriding. Variants and density are props on `Root`, not ad hoc class strings at call sites. Where a slot needs a real control it renders `Button` from `ui/` rather than a styled `