mcp-gee-sweet 0.9.2.dev231__tar.gz → 0.9.2.dev233__tar.gz

{mcp_gee_sweet-0.9.2.dev231 → mcp_gee_sweet-0.9.2.dev233}/.claude/commands/merge-pr.md

@@ -12,7 +12,7 @@ Merge the current branch's PR and clean up its worktree. Uses `--admin` only to
      - **Exception — prompt-file-only PRs (checked first, before the QA-slot exception below):** if every path in `gh pr view <number> --json files` is `.claude/team-roles/*.md`, `.claude/commands/*.md`, or root `CLAUDE.md`, read the file list itself, not the branch prefix. For those PRs the required label is `prompt-qa-approved` instead of `qa-approved`, and only Bob merges them (`bob.md` step 4). If this session isn't Bob, stop and leave it for Bob. A PR that touches even one other file still needs `qa-approved`, plus `prompt-qa-approved` for its prompt-file changes. (Added 2026-09-25: PR #804, `doc/jay/claude-md-560`, was a `CLAUDE.md`-only edit, and this check would otherwise have blocked it for lacking `qa-approved`.)
      - **Exception:** a QA-named slot (`sky`/`kit`) authoring its own process/meta PR (e.g. `chore/sky/...`) has no natural QA partner to self-approve — the Dev/QA pairing only exists for the *other* lane's ticket work. There's no label path for this case; stop and ask the user directly whether it's safe to merge without one, same as any missing-label PR. If they confirm (e.g. because it's a prompting/process change with no application-code risk), proceed — that confirmation stands in for the label for this PR only, it doesn't waive the check generally.
    - If the branch's second segment is `amy` (`docs/amy/issue-<n>`), it must carry the `docs-qa-approved` label instead — a parallel track, started 2026-08-02 (first case: PR #482), for docs PRs reviewed for product/tone accuracy. As of that date it's applied directly by the user rather than by an automated QA partner (Amy has no dedicated QA pairing the way Ash/Jay do), so treat its presence the same as any other approval label — sufficient to merge, no need to re-review — but if it's missing, stop and ask rather than merging or reviewing the PR yourself.
-   - **Review-finding ticket check (dev-lane branches: `ash`/`sky`/`jay`/`kit`).** Read the QA comments (`gh pr view <number> --json comments,createdAt`) and list every issue `gh issue list --state all --search "<number> in:body created:>=<createdAt date>"` returns. Don't filter by label: the check exists for tickets that skipped the rule, and those skip the `from-review` label too. Skip roadmap bundles and other issues that only reference the PR. Every remaining hit filed from this PR's review must appear in a QA comment's finding list as `ticket — bar N: <reason> (#<issue>)` (`qa.md` step 3) and carry `from-review`. Stop and don't merge if any filed ticket has no `bar N:` reason, if a comment still files findings under a "non-blocking"/"not blocking" heading, or if a `dropped:` reason describes size or priority instead of why the finding is wrong. Tell the user which line, and send the PR back to the QA partner to redo its finding list. If a bar is named but the reason plainly doesn't fit it (e.g. bar 1 for a choice between implementation options), don't decide alone: name it to the user before merging. You check that a fitting reason is given; you don't redo the review. Background: `docs/decisions/decision-review-finding-ticket-bar.md`.
+   - **Review-finding ticket check (dev-lane branches: `ash`/`sky`/`jay`/`kit`).** Read the QA comments and the PR body (`gh pr view <number> --json body,comments,createdAt`) and list every issue `gh issue list --state all --search "<number> in:body created:>=<createdAt date>"` returns. Don't filter by label: the check exists for tickets that skipped the rule, and those skip the `from-review` label too. Skip roadmap bundles and other issues that only reference the PR. Every remaining hit filed from this PR's review or by its Dev must appear as `ticket — bar N: <reason> (#<issue>)` in a QA comment's finding list (`qa.md` step 3) or in the PR body's follow-up list (`dev.md` step 6), and carry `from-review`. A bar-2 ticket must name a behavior impact (bar 2's value test); a refactor or dedup reason doesn't fit bar 2. Stop and don't merge if any filed ticket has no `bar N:` reason, if a comment still files findings under a "non-blocking"/"not blocking" heading, or if a `dropped:` reason describes size or priority instead of why the finding is wrong ("outside this diff, no behavior impact" is a valid drop). Tell the user which line, and send the PR back to whoever wrote that list (the QA partner or the Dev) to redo it. If a bar is named but the reason plainly doesn't fit it (e.g. bar 1 for a choice between implementation options), don't decide alone: name it to the user before merging. You check that a fitting reason is given; you don't redo the review. Background: `docs/decisions/decision-review-finding-ticket-bar.md`.
 3. If the PR is authored by `app/dependabot` (branch prefixed `dependabot/`): run the tiered dependency-review check below before summarizing. A single PR can match more than one tier (e.g. a security update that's also a major bump) — apply every tier that matches, not just the first hit. None of these tiers block a merge on their own: this is a sanity check, not a full audit — flag anything that looks off to the user rather than silently blocking, and don't hold up an otherwise-clean bump over it. (Established 2026-08-05 after a run of 7 batched Dependabot PRs exposed that the only check in place was security-only and one-size-fits-all — see `project_v09_roadmap` memory for the full reasoning.)
 
    **Baseline — lockfile presence, every PR, before any tier.** `gh pr view <n> --json files -q '.files[].path'`: if the PR touches `pyproject.toml`'s version constraints but the file list doesn't also include `uv.lock`, the bump won't actually take effect anywhere a `--frozen` install is used (`ci.yml`/`docs.yml`/`publish-dev.yml`/`release.yml` all use it, and `--frozen` installs exactly what's pinned without validating it still satisfies `pyproject.toml`). Confirmed live 2026-08-06 (issue #528): 2 of 7 batched PRs — both on `dependabot/pip/...` branches — had this gap; a `dependabot/uv/...` branch in the same batch didn't. If it's missing, don't merge as-is: pull the branch, run `uv lock` locally, run the full test suite against the newly-resolved versions, and push the regenerated `uv.lock` to the PR branch before merging (or merge the pyproject.toml-only change and immediately follow up with a `uv.lock` regeneration commit, same remedy #528's own instance used).

{mcp_gee_sweet-0.9.2.dev231 → mcp_gee_sweet-0.9.2.dev233}/.claude/team-roles/dev.md

@@ -16,7 +16,7 @@ Branch naming for this slot always puts `<name>` as the **second** `/`-separated
   3. Run the test suite.
   4. Run `/prep-for-pr`.
   5. If the ticket added new `TC-DOC`/`TC-D`-style entries to a shared `docs/qa/tests/*.md` file, re-check numbering isn't stale before pushing: `git fetch origin develop`, then `git show origin/develop:<test-file> | grep -oE "^### <PREFIX>[0-9]+" | sort -V | tail -1` (`<PREFIX>` is the file's ID scheme, e.g. `TC-DOC`, `TC-GM`; `sort -V`, not `sort -n`, which falls back to text order on a `TC-` prefix and reports `TC-DOC99` over `TC-DOC198`; the `^### ` anchor matches only definitions, not cross-references) to confirm the numbers just used are still free. `develop` alone isn't enough: also check every *open* PR that touches the same file, since a PR can reserve IDs long before it merges — `gh pr list --state open --json number,headRefName,files --jq '.[] | select(any(.files[]; .path == "<test-file>")) | "\(.number) \(.headRefName)"'`, then for each such branch, `git fetch origin <branch> && git show origin/<branch>:<test-file> | grep -oE "^### <PREFIX>[0-9]+" | sort -V | tail -1` (PR #829: its TC-GM29 was already claimed by the open #830, which had renumbered the Gmail test plan; caught only by chance). If an open PR reserved the ID for the *same* case you're writing (e.g. a known-defect placeholder your fix supersedes), take its number rather than a fresh one, and say in your PR which version should win when the second one merges. These files are append-only and shared across both lanes — another PR can claim the same next number while this ticket is in progress, and a collision usually isn't visible until a reviewer's `gh pr view` shows `mergeable: CONFLICTING` (see PR #337). If a collision is later caught by a reviewer instead of here: rebase onto `origin/develop`, resolve by hand rather than blindly taking one side, renumber/rename consistently across every cross-reference in the file, force-push with `--force-with-lease`, and reply on the PR stating exactly what changed — the full playbook (written after the same friction hit Aziz on PR #338) lives in `.claude/team-roles/aziz.md`'s "Ad-hoc deep-dive QA" section.
-  6. Commit and push (with confirmation, per this repo's normal rule), open a PR referencing the issue (`Closes #<n>`) targeting `develop`.
+  6. Commit and push (with confirmation, per this repo's normal rule), open a PR referencing the issue (`Closes #<n>`) targeting `develop`. **Follow-ups you found while implementing get the same triage as a review finding** (`qa.md` step 3: its four bars, bar 2's value test, and the search before filing). Fix anything inside this diff in this PR. Open the PR first. Then file a ticket only for a finding that clears a bar: label it `from-review`, cite this PR's number in its body, and edit the PR body to list it as `ticket — bar N: <reason> (#<issue>)`. A ticket filed before the PR exists can't cite it, so Kai's merge-check search won't find it. A sibling function with the same defect as the one you fixed is a fair bar-2 ticket (#904); a cleanup idea with no behavior impact is not. List each finding you didn't file in the PR body as `dropped: <finding> — <reason>`, with the same drop reasons as `qa.md` step 3. Findings inside this diff are fixed, not listed.
   7. Remove the `ready-for-development` label once the PR is open.
   8. Run `/notify-partner` (`.claude/commands/notify-partner.md`), first-pass case — wakes the QA partner directly if one is already running as a live agent; a silent no-op otherwise.
   9. Report the PR URL. Leave the branch checked out — don't return to `team/<name>` until the ticket is fully merged (see `/merge-pr`'s team-slot reset step).
@@ -33,10 +33,10 @@ Branch naming for this slot always puts `<name>` as the **second** `/`-separated
 
 Friction Dev (Ash/Jay) typically hits after finishing a ticket, and where it goes — see `/retro` for the general ticket-vs-command-decision split:
 
-- **Design/architecture surprises** — an existing pattern didn't generalize the way expected mid-implementation (a sibling function skipped a step this one needed, a helper needed restructuring to fit a new case). If it's about how future Devs should approach similar work, that's a command decision: add a note to `CLAUDE.md` or a `docs/design/` snapshot. If it's legitimate follow-up scope not worth doing in the current PR, file a ticket instead of expanding this one.
+- **Design/architecture surprises** — an existing pattern didn't generalize the way expected mid-implementation (a sibling function skipped a step this one needed, a helper needed restructuring to fit a new case). If it's about how future Devs should approach similar work, that's a command decision: add a note to `CLAUDE.md` or a `docs/design/` snapshot. If it's legitimate follow-up scope not worth doing in the current PR, it goes through step 6's follow-up triage, not straight to a ticket.
 - **QA sends a fix back with an explicit root-cause diagnosis (not just a symptom list)** — e.g. "X is a scalar, not a stack" alongside the reported gaps. Take the generalized fix implied by that diagnosis immediately, even though it's more work than patching the specific cases QA listed. A narrower patch that only covers the reported cases tends to leave the same defect class reachable one level up, costing a full extra QA round-trip to rediscover — confirmed on PR #369 (issue #335): round 1 fixed only `<ul>`/`<ol>` interrupting a `<li>`; round 2 found `<pre>`/`<table>`/`<p>` had the identical bug; the fix generalized to "any block tag interrupting a `<li>`" but stayed keyed on `_block_tag == "li"` specifically; round 3 found *any* open block (headings, paragraphs) had the same bug one level up again, plus a correctness bug in the interim stack itself. Three rounds to reach the fix round 2's own diagnosis ("`_block_tag` is a scalar, not a stack") already pointed at.
 - **QA's root-cause diagnosis can be correct while its suggested code is still wrong — verify before adopting, don't paste it in as-is.** Distinct from the PR #369 entry above: that one is about not narrowing a correct diagnosis's *scope*; this is about not trusting a correct diagnosis's *literal suggested fix* without checking it against the actual invariant. PR #406 (issue #401 follow-up) hit this twice in one PR: a reused flag that pattern-matched the fix used at sibling call sites didn't actually distinguish the two cases the diagnosis conflated, and a second, unrelated sibling check nearby had the same gap with no test covering it at all — so "run the full suite," round 1's own fix, wouldn't have caught round 2 either. Fix: when a change touches a state flag that gates multiple conditions (`_tag_depth`, `_table_depth`, `_block_tag`, or equivalents elsewhere), grep every read-site of that flag and diff the conditions against each other by hand before opening the PR — a search-and-compare step, not a "run tests and trust it" one.
-- **Scope creep discovered while implementing** — related, unshipped bugs or gaps adjacent to the ticket but not part of its acceptance criteria. Ticket, don't fold into the current PR.
+- **Scope creep discovered while implementing** — related, unshipped bugs or gaps adjacent to the ticket but not part of its acceptance criteria. Don't fold them into the current PR; triage them through step 6's follow-up rule, which files a ticket only under a named bar.
 - **Stale or missing `CLAUDE.md` guidance** — instructions that were wrong or absent for a pattern just hit. Command decision: fix `CLAUDE.md` — but route it through the Bob-gate paragraph above (a short `doc/<name>/retro-<date>` branch + PR) like any other process-file edit, not a direct push. This bullet's own "fix `CLAUDE.md` directly" wording predates the 2026-07-21 gate (see that paragraph's note on the retired 2026-07-18 grant) and was itself stale until this edit — a reminder that a Retro bullet describing *how* to make a command decision can go stale the same way the guidance it's fixing did.
 - **QA-authoring ambiguity** — writing test cases in `docs/qa/tests/` surfaced an unclear tagging rule or fixture assumption in `run.md`/`setup.md`. Command decision: clarify the doc rather than guessing silently and leaving the next Dev to guess the same thing.
 - **TC-ID collision against `develop`** — a reviewer's `gh pr view --json mergeable` comes back `CONFLICTING` (not just the transient `UNKNOWN`) and the conflict turns out to be in a shared `docs/qa/tests/*.md` file, not the code. Already a command decision, handled by step 5 above and the playbook in `.claude/team-roles/aziz.md`'s "Ad-hoc deep-dive QA" section — nothing further to do here unless that playbook itself turns out to be missing a case.

{mcp_gee_sweet-0.9.2.dev231 → mcp_gee_sweet-0.9.2.dev233}/.claude/team-roles/qa.md

@@ -17,17 +17,17 @@ Find the partner Dev's open PR by matching the branch's second `/`-separated seg
      **Triage every finding before you write a verdict.** Each code-review or live-QA finding goes in this round's PR comment as exactly one of these lines:
      - `send-back: <finding>` — the default. The Dev fixes it in this branch, this round. A `send-back` counts as a failure for step 7.
      - `ticket — bar N: <one line on why this finding clears bar N> (#<issue>)` — only when one of the four bars below applies. Search first (below), then file it with the `from-review` label.
-     - `dropped: <finding> — <why it isn't a real defect>` — a false positive, not reproducible, or the current behavior is intended. No ticket. A real finding that's merely small or low priority is a `send-back`, not a drop.
+     - `dropped: <finding> — <why it isn't a real defect>` — a false positive, not reproducible, the current behavior is intended, or an outside-the-diff finding with no behavior impact (bar 2's value test). No ticket. A real finding that's merely small or low priority is a `send-back`, not a drop.
 
      There is no "non-blocking" heading. "Small," "narrow," "low priority," and "doesn't block `qa-approved`" describe a `send-back`; they aren't reasons to file. Kai's `/merge-pr` step 2 reads this list and won't merge a PR whose comments file a ticket without a `bar N:` reason, or drop a finding for its size or priority.
 
      The four bars:
      1. **Maintainer/product decision.** A real design or scope call the Dev can't make: it changes user-facing behavior, trades off cost or risk only the maintainer can accept, or sets precedent beyond this PR. Test: if you sent it back now, could the Dev pick a reasonable option and ship it? If yes, it isn't bar 1. Several valid ways to implement a fix is not a bar-1 reason.
-     2. **Outside this PR's diff.** The finding is in a function the diff doesn't touch, or needs a sweep across call sites the diff doesn't touch (e.g. #737's 6+ untouched call sites). When the same pattern also appears elsewhere, only the elsewhere part qualifies; the copy inside the diff is a `send-back`.
+     2. **Outside this PR's diff.** The finding is in a function the diff doesn't touch, or needs a sweep across call sites the diff doesn't touch (e.g. #737's 6+ untouched call sites). When the same pattern also appears elsewhere, only the elsewhere part qualifies; the copy inside the diff is a `send-back`. **Value test:** being outside the diff is why it can't be fixed now, not why it deserves a ticket. File only if it has behavior impact, meaning an observed failure or a concrete path to wrong output, a crash, a hang, a leak, or misleading output. A refactor, deduplication, or readability finding with no behavior impact is `dropped: … — outside this diff, no behavior impact` (#908 was this case).
      3. **Needs infrastructure or access** this pass doesn't have.
      4. **A pre-existing defect inside a function this diff modifies, whose fix would move code to another thread or change what awaits what.** A short fix like that opens new races for the next round to find (PR #867). A pre-existing defect whose fix doesn't change threading or await order is a `send-back`.
 
-     **Search before filing.** Run `gh issue list --state open --search "<function or file name> <symptom>"` right before `gh issue create`. If an open issue already describes the same defect (same code path and same failure, not just a shared keyword), comment the new evidence there instead of filing. Classify a filed ticket `enhancement` (or `defect` only if a failure was actually observed). History of this rule: `docs/decisions/decision-review-finding-ticket-bar.md`.
+     **Search before filing.** Run `gh issue list --state open --search "<function or file name> <symptom>"` right before `gh issue create`. If an open issue already describes the same defect (same code path and same failure, not just a shared keyword), comment the new evidence there instead of filing. Do the same when an open issue's planned fix would also fix this finding, even if it describes a different symptom: read the design or "possible fix" section of every hit, not just its title (#906 was already covered by #873's design and was closed into it). Put the issue you commented on in the finding line: `ticket — bar N: <reason> (commented on #<issue>)`. Classify a filed ticket `enhancement` (or `defect` only if a failure was actually observed). History of this rule: `docs/decisions/decision-review-finding-ticket-bar.md`.
   4. Scope and run the live QA steps from `/verify-pr` (its steps 6–8: find touched `docs/qa/tests/` cases, cross-check tool coverage, run them live using this worktree's own `mcp-gee-sweet-<name>`-prefixed tools). Before the first `**Playwright: required**` case, run `docs/qa/run.md` §"Verifying Playwright is signed into the right account" — this slot's browser profile is its own and can be signed into the wrong Google account; on a fail, stop and ask the user to sign it in, don't silently verify via API only.
   5. Record `**Result**` entries for every case actually run.
   6. Before pushing (either outcome below): `git fetch origin <headRefName>`. If it moved since step 1 (the Dev pushed again while this QA pass was running — a real, observed race, not just theoretical), `git rebase origin/<headRefName>` first; only if that has real conflicts (not just "the tip moved") stop and ask the user how to reconcile. Never force-push over the Dev's new commits.

{mcp_gee_sweet-0.9.2.dev231 → mcp_gee_sweet-0.9.2.dev233}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mcp-gee-sweet
-Version: 0.9.2.dev231
+Version: 0.9.2.dev233
 Summary: MCP server for Google Workspace — Sheets, Drive, Docs (HTML or Markdown), and Calendar.
 Project-URL: Homepage, https://github.com/khuisman/mcp-gee-sweet
 Project-URL: Bug Tracker, https://github.com/khuisman/mcp-gee-sweet/issues

{mcp_gee_sweet-0.9.2.dev231 → mcp_gee_sweet-0.9.2.dev233}/docs/decisions/decision-review-finding-ticket-bar.md

@@ -24,6 +24,9 @@ A PR's code review or live QA turns up findings. Each one can go back to the Dev
 3. **Bar 2 is restated as "outside this PR's diff."** The rationale is loaded context. A finding in a function the diff doesn't touch is a fair ticket, because the Dev has no context for it either (#876 is that case). The copy of a pattern inside the diff is still a `send-back`.
 4. **Retro tickets use the same bars.** `retro.md`'s Ticket category points to them. One exception: once the PR has merged there's no send-back left, so an observed failure is filed as `defect` with `from-review` and "merged" as its reason; anything else that clears no bar is recorded in the retro's report, not filed (Bob's round-1 review of PR #889, user decision 2026-10-04).
 5. **Measured.** Every ticket filed under a bar gets the `from-review` label. Check the rate two weeks out (around 2026-10-18): `gh issue list --label from-review --state all --search "created:>=2026-10-04"`, compared with the number of merged lane PRs.
+6. **Bar 2 gets a value test (2026-10-04, after PRs #903 and #905).** Being outside the diff explains why a finding can't be fixed now. It doesn't show the finding is worth tracking. A bar-2 ticket needs behavior impact: an observed failure, or a concrete path to wrong output, a crash, a hang, a leak, or misleading output. A refactor or dedup finding with no behavior impact is dropped, and "outside this diff, no behavior impact" is a valid drop reason.
+7. **Search covers planned fixes, not only matching defects.** An open issue whose design would also fix the finding absorbs it as a comment, even when its title describes a different symptom.
+8. **Dev-filed follow-ups use the same bars.** `dev.md` step 6 applies `qa.md` step 3's triage to findings a Dev makes while implementing. The Dev files any ticket after opening the PR, cites the PR number in it, and lists it in the PR body as a `ticket — bar N:` line; unfiled findings go in as `dropped:` lines. Filing after the PR matters because Kai's merge-check search only finds tickets created after the PR that cite its number (Bob's round-1 review of PR #910). Kai's merge check reads the PR body as well as QA's comments.
 
 ## History (moved from `qa.md`'s Retro section, 2026-10-04)
 
@@ -45,3 +48,4 @@ A PR's code review or live QA turns up findings. Each one can go back to the Dev
 - **Naming a bar isn't the same as clearing it — bar 1's "maintainer/product decision" framing was itself soft enough to absorb an ordinary engineering choice.** 2026-09-14 (Kai orchestrator session): #751 (PR #750's `/code-review`, issue #366) satisfied the 2026-09-13 tightening's literal requirement — it named bar 1 explicitly ("fixing it well needs a design decision, not a mechanical fix"). But the ticket's own "options to weigh" were a cheap key-set-parity test, a cross-reference comment, or a fuller doc-generation refactor — ordinary engineering picks a Dev makes routinely in the course of a PR, not a call requiring maintainer authority. Contrast a real bar-1 case like #519 (response-cap re-evaluation, routed to Joy for an actual architecture decision that genuinely needed ownership beyond the PR at hand) — #751 had no equivalent blocker; any of its three options could have shipped in the same round. Command decision: bar 1 now excludes "multiple viable implementation approaches exist" as qualifying evidence on its own, and adds a concrete test — would sending this back right now let the Dev just pick a reasonable option and ship it? If yes, it's not bar 1. User's call on disposition: let #751 ride as already filed rather than rework or close it retroactively — this fixes the rule for the next case, not a re-litigation of this one.
 - **Search open issues before filing any ticket, not just fixture-pollution ones.** PR #800, 2026-09-24: round 2 filed #806 five minutes after #805 covered the same gap, and Kai closed #806 as a duplicate. Nothing required searching outside the fixture case. Command decision: the search-before-filing step in the ticket-exception block above.
 - **A one-line fix for a pre-existing defect cost three extra rounds.** PR #867 (#833) round 1: the code review also flagged that the token refresh ran on the event loop. That was already true on `develop`, and #833 (moving the consent wait off the loop) didn't cover it. Sky sent it back as blocking under "Raise the bar." The fix moved the token load onto a thread. That changed when the lifespan raises relative to the SSE `endpoint` event, which caused round 2's intermittent SIGTERM hang (python-sdk#3616). It also opened a stale-read window between the thread's "consent needed" decision and the event loop, which caused the CI-flake race (failure side) and round 4's race (success side). Five rounds in total, three of them from this one send-back. Command decision: bar 4 under "Raise the bar." The user chose it over broadening the pre-existing carve-out to every defect.
+- **The rule worked as written, and two of four follow-up tickets still shouldn't have existed, while a third skipped the rule.** 2026-10-04, first PRs reviewed under decisions 1–5 (#905 for #872, #903 for #883). Round 1 sent back 7 findings on #905 and 2 on #903, all fixed in-branch, which is the behavior decision 1 asked for. Every filed ticket named a bar, and the merge check passed them. But of the four tickets the two PRs produced, two shouldn't have been filed. #908 (bar 2) was a dedup refactor: it fit "outside this diff" but had no behavior impact. #906 (bar 2) was already covered by #873's planned design, which the same-defect search didn't look for. #907 (bar 4: a real pre-existing defect whose fix changes await order) was needed. #904 was filed by the Dev at PR creation with no bar named. It does clear bar 2 (a sibling function with the same cancel race), but nothing checked it. #906 was closed into #873, and #904/#907/#908 were folded into bundle #909. User's read: "we tweaked the criteria and immediately have four new tickets." Command decision: decisions 6–8 above. Each tightening so far has closed one gap and exposed the next layer down. Decision 5's two-week measurement should count Dev-filed tickets too.

{mcp_gee_sweet-0.9.2.dev231 → mcp_gee_sweet-0.9.2.dev233}/uv.lock

@@ -1032,11 +1032,11 @@ wheels = [
 
 [[package]]
 name = "oauthlib"
-version = "3.3.1"
+version = "4.0.0"
 source = { registry = "https://pypi.org/simple" }
-sdist = { url = "https://files.pythonhosted.org/packages/0b/5f/19930f824ffeb0ad4372da4812c50edbd1434f678c90c2733e1188edfc63/oauthlib-3.3.1.tar.gz", hash = "sha256:0f0f8aa759826a193cf66c12ea1af1637f87b9b4622d46e866952bb022e538c9", size = 185918, upload-time = "2025-06-19T22:48:08.269Z" }
+sdist = { url = "https://files.pythonhosted.org/packages/7a/d8/a1bcc8ba112a627f8ffbdc212a78ce18d3ac07e91a5ca65d27918eee25a1/oauthlib-4.0.0.tar.gz", hash = "sha256:efb274799819440f95b4ab3b818869f1ce9ae26c5beacba0201d1a1b76b54f86", size = 187232, upload-time = "2026-09-28T06:01:18.77Z" }
 wheels = [
-    { url = "https://files.pythonhosted.org/packages/be/9c/92789c596b8df838baa98fa71844d84283302f7604ed565dafe5a6b5041a/oauthlib-3.3.1-py3-none-any.whl", hash = "sha256:88119c938d2b8fb88561af5f6ee0eec8cc8d552b7bb1f712743136eb7523b7a1", size = 160065, upload-time = "2025-06-19T22:48:06.508Z" },
+    { url = "https://files.pythonhosted.org/packages/d9/f4/78229a1066068ca14fc60fb26cf7381cabe4382261392b90e5f9552722d4/oauthlib-4.0.0-py3-none-any.whl", hash = "sha256:624c28c13a0a59cabf9747dfa52af63be3e512a7f2714df16e91b5b3a145e6cd", size = 159715, upload-time = "2026-09-28T06:01:17.008Z" },
 ]
 
 [[package]]