chore(release): release Buzz Mobile version 0.4.7 - #2137
Merged
Merged
Conversation
brow
marked this pull request as draft
July 19, 2026 19:46
Co-authored-by: npub1ux8n2yfs8qfvgd75s7kyhar2mztac355v6vmrz4juc9l3msw4pgstums9e <e18f3511303812c437d487ac4bf46ad897dc46946699b18ab2e60bf8ee0ea851@sprout-oss.stage.blox.sqprod.co> Signed-off-by: npub1ux8n2yfs8qfvgd75s7kyhar2mztac355v6vmrz4juc9l3msw4pgstums9e <e18f3511303812c437d487ac4bf46ad897dc46946699b18ab2e60bf8ee0ea851@sprout-oss.stage.blox.sqprod.co>
brow
force-pushed
the
mobile-release/0.4.7
branch
from
July 19, 2026 19:46
1eba2dc to
58bf601
Compare
Contributor
Author
|
@codex review |
Contributor
Author
|
@builderbot review |
|
To use Codex here, create a Codex account and connect to github. |
brow
marked this pull request as ready for review
July 19, 2026 19:58
brow
enabled auto-merge (squash)
July 19, 2026 19:58
BradGroux
pushed a commit
to BradGroux/buzz
that referenced
this pull request
Aug 23, 2026
Signed-off-by: npub1ux8n2yfs8qfvgd75s7kyhar2mztac355v6vmrz4juc9l3msw4pgstums9e <e18f3511303812c437d487ac4bf46ad897dc46946699b18ab2e60bf8ee0ea851@sprout-oss.stage.blox.sqprod.co> Co-authored-by: npub1ux8n2yfs8qfvgd75s7kyhar2mztac355v6vmrz4juc9l3msw4pgstums9e <e18f3511303812c437d487ac4bf46ad897dc46946699b18ab2e60bf8ee0ea851@sprout-oss.stage.blox.sqprod.co>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…k#2131) Plans Feature block#2131 and its six child tasks (block#2137-block#2142). The reading changed the plan's shape: roughly a third of the Feature is already built. verify-claims/SKILL.md already carries the mandatory framing, the isolation and withhold rules, the four verdicts, the run-twice step and the accepted-cost note; screen-sensitive/SKILL.md already documents the whole ATTRIBUTION/ROSTER_DATA/AMBIGUOUS protocol. What is genuinely missing is narrower and more important: nothing in the pack says what verifier stdout counts as which verdict, and neither draft-page nor update-page wires the gate into its procedure at all - update-page does not mention it once. Three OPEN items are left for a human, not decided here. Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…tract (block#2137) Adds sections 2a, 2b and 2c to verify-claims/SKILL.md. Until now the skill named three verdicts and never said how to recognise one in a command's output, so the gate could not parse its own answer. 2a - the exact fail-loud message when $PROFESSOR_VERIFIER_CMD is unset, modelled on professor.py:63's $PROFESSOR_PACK_ROOT wording. 2b - the response grammar. The whole response is matched against it; a verdict is never searched for inside a response. The verdict literal must EQUAL the text before the separator, not be contained in it, which is what makes SUPPORTED being a substring of NOT_SUPPORTED and PARTIALLY_SUPPORTED harmless. Case sensitivity and whitespace are pinned. Three acceptance examples and three rejection examples: text before the literal, a verdict word inside prose that negates it, and a valid verdict line surrounded by other output. That last one matters because any verifier narrating its work would otherwise be trusted. 2c - what happens when there is no verdict. Disposition is block, never SUPPORTED. Covers parse failure, non-zero exit despite well-formed stdout, a 120-second per-dispatch timeout, and a response that stops before completing the grammar. The timeout names the dispatching agent as its enforcer, because dispatch is deliberately not a professor.py subcommand and so never reaches professor_lib/proc.py - nothing else can bound the call. One correction to the plan, made while building: STEP 1's done-when asked for a REJECTION example of 'NOT_SUPPORTED: ...'. That is wrong - a bare NOT_SUPPORTED with a reason is well-formed and must be accepted as NOT_SUPPORTED. The intent was to prove the substring collision cannot happen, which is what the new acceptance examples do. The plan line is corrected in the same commit rather than left to contradict the build. Verification: python3 launchpad/agents/the-professor/tools/check_professor.py --offline -> ALL NETWORK-FREE CHECKS PASSED (same invocation CI uses). Not verified: this step is procedure text, and the harness asserts nothing about SKILL.md prose - no automated check covers it either way. STEP 3 is the first thing that exercises this contract for real. Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…k#2137, block#2141) Five real dispatches against real claims, 2026-09-16, found that PARTIALLY_SUPPORTED is not reachable through the documented dispatch, and found why: section 2b requires the verdict BEFORE the reason, so a verifier generating left to right commits to a literal before doing the reasoning that decides which literal is right. It can then only correct itself inside the reason, where the equality rule gives the correction no effect. One response read: NOT_SUPPORTED: ... -- wait, the first two assertions are established, so the correct verdict is PARTIALLY_SUPPORTED. Sending the three verdicts' definitions did not fix it. Sending an explicit ordered procedure for composing them did not fix it either; controls held (SUPPORTED and NOT_SUPPORTED claims kept their verdicts), so it is positional, not prompt drift. This commit does NOT fix the ordering -- that is a grammar change and a separate decision. It adds section 2d: a reason naming a verdict literal other than the one it follows is contradictory, and blocks. Matched as whole tokens, longest first, so the SUPPORTED inside NOT_SUPPORTED is not a false hit. Section 2's send-list now asks the verifier for this, so the rule does not produce blocks it was never given a chance to avoid. Why this earns its place even though the observed collapses were all in the safe direction: the mirror image, `SUPPORTED: ... though strictly only partially supported`, parses as SUPPORTED under 2b alone and would pass the gate. Nothing else in the contract catches it. Named limit, not solved: 2d checks naming, not meaning. Of four responses whose reasoning disagreed with their emitted verdict, it catches the two that named a literal and misses the two that only described the disagreement. Signed-off-by: Serina Mcfall <serina.mcfall@gmail.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…lock#2137, block#2141) The response grammar was <VERDICT>: <reason>, which required the answer before the reasoning that decides it. A verifier generating left to right committed to a literal at its first token and could only correct itself inside the reason, where the equality rule gave the correction no effect. PARTIALLY_SUPPORTED was unreachable on every honestly-partial claim tried. Section 2b now specifies exactly two lines -- reason first, verdict alone on line two: The span supports two of the three conditions. PARTIALLY_SUPPORTED Everything the old grammar earned is kept: whole-response matching, equality rather than containment, a one-line reason, no narration tolerated. Only the position moved. Measured, same four claims, same procedure text, only the format block changed: claim verdict-first verdict-last A 1-based line counting (control) SUPPORTED SUPPORTED B raises ValueError (control) NOT_SUPPORTED NOT_SUPPORTED C two established, one absent NOT_SUPPORTED PARTIALLY_SUPPORTED D one established, one contradicted NOT_SUPPORTED PARTIALLY_SUPPORTED Controls held, so this is positional and not prompt drift. No response under the new ordering self-corrected or named a competing literal. Two further gains, both recorded in the file. Truncation is now safer: a cut-off response loses the verdict itself rather than keeping a complete-looking one above a missing justification, so a half-finished check can no longer look like a decided one. And section 2d is deliberately KEPT after its cause was removed -- the ordering fixed the mechanism that forced self-contradiction, not every route to one, and the contract has to hold for any configured $PROFESSOR_VERIFIER_CMD, not only the one this was measured on. Rejection examples rewritten for the new shape, including the old verdict-first form, which must now fail rather than be tolerated for compatibility. Every documented rejection was executed against a reference implementation of 2b+2d and rejects for the stated reason. Signed-off-by: Serina Mcfall <serina.mcfall@gmail.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…lock#2137) Both were confirmed High by the adjudicator over six review lanes, and both are internal contradictions inside sections this branch introduced in full. 1. Section 2c enumerated "a response with no reason" as a parse failure while section 2b's only test on line one was non-emptiness. So `.` and `-` passed as reasons, and so did the verdict literal repeated -- SUPPORTED above SUPPORTED parsed as a clean SUPPORTED from a verifier that reasoned about nothing. Line one now has two tests: it must contain at least one letter, and it must not equal a verdict literal ignoring case. Both degenerate shapes now fail. Named limit, stated in the file rather than left to be discovered: neither test establishes sentence-hood, so `x` still parses. This is a floor against degenerate responses, not proof a reason was given. 2. Section 2d's accepted-cost paragraph claimed its rule catches a reason ending "though strictly this is only partially supported" above a SUPPORTED verdict. It does not -- lowercase prose is not the literal PARTIALLY_SUPPORTED -- and the very next paragraph already said reasons that describe a contradiction without naming one pass untouched. The claim was falsified by its own successor paragraph, and it was the stated justification for keeping the rule at all, so a builder taking it seriously would have implemented case-insensitive phrase matching inside the reason and undone the equality discipline the rest of the file defends. The example is now uppercase PARTIALLY_SUPPORTED, which the rule really does catch. The lowercase phrasing moved into the "what it does NOT catch" paragraph as a second named uncaught shape, with an explicit note that an earlier draft wrongly gave it as a catch -- recorded rather than quietly swapped, because the wrong claim carried the section's justification. Section 2d now also states its matching is case-sensitive and upper-case, which section 2b pinned only for the verdict line. That ambiguity is what made the bad example look plausible. Widening to case-insensitive or to phrases would turn the check into a containment search over the reason -- the discipline 2b abandons containment to protect -- so the narrowness is the design, and it is now written down as such. Verified against a reference implementation of the amended rules: all three degenerate shapes now parse-fail; the uppercase example blocks; the lowercase one parses and is now correctly disclaimed rather than falsely claimed; and every previously-accepted real verdict and every documented rejection is unchanged. Harness green. The eleven Medium and Low findings are not addressed here and are being filed. Signed-off-by: Serina Mcfall <serina.mcfall@gmail.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
block#2137) The previous commit tried to make §2c's "a response with no reason" clause implementable by adding two tests to §2b's line one. A second review round found both tests defective, and they were: - "contains at least one letter" turns on a definition of letter that ASCII and Unicode disagree about on twelve of twenty-one sampled reasons. Under the ASCII reading -- what `grep '[a-zA-Z]'` and C-locale `[[:alpha:]]` give you -- a verifier reasoning in CJK, Cyrillic, Arabic or Devanagari has every correct verdict blocked as "no reason", reported against the claim as though the check failed. - "not equal to a verdict literal" bans exactly one spelling. `SUPPORTED.` defeats it, so do `**SUPPORTED**` and `"SUPPORTED"`; twenty-one of twenty-two measured mutations walked through. That equality-is-brittle property is load-bearing in the OPPOSITE direction fourteen lines below, where rejection example 4 relies on a trailing full stop defeating equality on line two. The tests are removed and §2c's clause with them. Line one is non-empty, and that is now stated as the limit it always was: the grammar does not establish that line one is a reason, that it relates to the claim, or that the verifier reasoned before answering. This follows the file's own existing pattern for a requirement it cannot enforce. §2 already says of isolation that it "rests on item 2 alone -- which is an instruction, not a boundary, and should be understood as such." Reason quality is the same shape: a semantic question whose only robust test is another model call, the cost this suite has twice refused. Subtraction resolves four findings at once rather than adding four more rules: the two defective tests are moot; the summary checklist's "never a case-insensitive match" is true again because no case-insensitive test remains; and §2d's case-sensitivity paragraph is accurate again, having been made false by test 2 in the same commit that added it. Verified against a reference implementation: §2d's three claimed non-triggers do not trigger and its one claimed trigger does; every real verdict and every documented rejection is unchanged. §2c's enumeration was also rewritten to name what §2b actually rejects, which drops its stale "three rejected shapes" count where §2b lists four -- a separately-reported finding that sat in the sentence being rewritten. What this gives up, stated rather than buried: a verifier that answers without reasoning is no longer distinguishable from one that reasoned. The previous commit only ever caught one literal spelling of that, so what is lost is the appearance of a check rather than a check. Signed-off-by: Serina Mcfall <serina.mcfall@gmail.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
Round 4's only finding, and the most useful one of the sequence. §2c ended "The full history is in the redesign doc." That was false: the redesign doc contained no trace of it and was never touched by the commit that made the claim. Verified -- zero hits for the distinctive terms, and the doc's last edit predates that commit. Fixed by writing the history rather than deleting the promise. The redesign doc gains decision 15 -- both failed §2c enumerations, what each broke in which direction, and the general rule that a section defining a rule is the only place that states it. §2c's pointer now names decision 15 and the file by path, matching the convention the rest of the skill already uses for cross-document references and which this one sentence alone ignored. WHY THIS ONE MATTERS BEYOND ITS SIZE. The previous commit was the first written with a claim-check applied, and it still shipped a false claim -- which was the test the reviewer was asked to run. The claim-check tested claims the file makes about ITSELF: its own line counts, its own rules, its own sections. Every one of those passed and was independently confirmed passing this round. It never tested a claim about ANOTHER document, and that was the single outward-pointing claim in the commit. So the root cause holds -- nothing tested the document's assertions -- but its first implementation drew the scope too narrowly. A cross-document pointer is a claim, and it is the cheapest kind to check: does the target exist, and does it contain what you said it contains. The check now covers both, and was mutation-tested rather than asserted: restoring the vague "full history is in the redesign doc" pointer fails it, and pointing at a decision number the target does not contain fails it. Running that check against the real file immediately found two defects in the CHECK itself, both the same class: it matched line by line against a file hard-wrapped at 88 columns, so "exactly two / constraints" read as absent and "decision 15 in / `path`" silently never fired at all. A check that skips without saying so is worse than no check. It now matches against a whitespace-flattened copy. Signed-off-by: Serina Mcfall <serina.mcfall@gmail.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…xplained (block#2137) qa round 4: three High, three Medium, two Low. One High (the false redesign-doc pointer) was already fixed by 77d8087; the rest are here. The High that mattered: "Line one carries exactly two constraints ... deliberately no third" was false. The same bullet, two lines above, called it "the single-sentence reason this step already requires" -- a third property, stated where matching is defined. Round 3 said "one test" and was wrong by two; the round-3 fix said "exactly two, no third" and was wrong by one, more specifically. And §2c's new pointer made §2b the whole definition, so there was nowhere left to arbitrate: a three-sentence reason parsed SUPPORTED under one reading and blocked under the other. Fixed at the source, not explained away. The word "single-sentence" is gone from the bullet that defines matching, which is where it read as testable. §2 still asks for one sentence; §2b now says its length is not matched against and that a multi-sentence reason is not a parse failure. My first attempt added a paragraph distinguishing "asked for" from "tested" and left the adjective in place -- that worked, but it answered a contradiction instead of removing it, and it cost 52 words. Deleting one adjective costs four. Also: "a reachable fourth verdict" named UNSOURCED, which is never dispatched and has no response at all; the verdict the ordering made unreachable was PARTIALLY_SUPPORTED. "Nine real dispatches" was an unsourced count no committed evidence supports, so the number is gone rather than defended. §2b's line-count clarifier read exhaustively while omitting zero, which the removed enumeration used to cover. The "What this gate does not solve" bullet restated §2b's line-one constraints -- a third normative copy, introduced by the commit arguing that second copies drift -- and now points instead. The checklist item forbidding a generic "verification failed" while mandating pass-through of the verifier's text is rescoped: the prohibition is on the reporting agent substituting its own summary, not on what the verifier wrote. Measured, because the previous round's claim to have shrunk the surface was false: 5560 -> 5564 words. Near-neutral, where the round-4 finding recorded 5365 -> 5560 for the commit that claimed to be reducing it. 11/11 grammar behaviours reproduce, including the three qa raised -- a three-sentence reason, an empty response and a whitespace-only response. The claim-check caught its own staleness this round: it verified the "exactly two" claim, so deleting that claim made it fail. A check failing because its subject was removed is stale, not a finding. It now accepts either a correct count or no count with the untested property named. Signed-off-by: Serina Mcfall <serina.mcfall@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed?
Bump Buzz Mobile from
0.4.6-rc.1+1to0.4.7+1and add the generatedmobile-v0.4.7changelog entry.Why?
Cut a new mobile build from current
mainso the app-store screenshots can be updated.How is it tested?
Release recipe validation passed, including the mobile test suite and repository pre-push checks.
Release steps
mobile-v0.4.7tag.mobile-v0.4.7to the private Buzz mobile Buildkite pipeline assprout_ref.Screenshot evidence is not applicable because this PR only changes release metadata. The tagged build is intended to support separate app-store screenshot capture.
🤖 This PR was authored with an agent.