Skip to content

chore(release): release Buzz Mobile version 0.4.7 - #2137

Merged
brow merged 1 commit into
mainfrom
mobile-release/0.4.7
Jul 19, 2026
Merged

brow merged 1 commit into
mainfrom
mobile-release/0.4.7

Conversation

@brow

@brow brow commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

What changed?

Bump Buzz Mobile from 0.4.6-rc.1+1 to 0.4.7+1 and add the generated mobile-v0.4.7 changelog entry.

Why?

Cut a new mobile build from current main so 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

  1. A human merges this draft release PR. The merge workflow creates the mobile-v0.4.7 tag.
  2. A human feeds mobile-v0.4.7 to the private Buzz mobile Buildkite pipeline as sprout_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.

@brow
brow requested a review from a team as a code owner July 19, 2026 19:45
@brow
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
brow force-pushed the mobile-release/0.4.7 branch from 1eba2dc to 58bf601 Compare July 19, 2026 19:46
@brow

brow commented Jul 19, 2026

Copy link
Copy Markdown
Contributor Author

@codex review

@brow

brow commented Jul 19, 2026

Copy link
Copy Markdown
Contributor Author

@builderbot review

@chatgpt-codex-connector

Copy link
Copy Markdown

To use Codex here, create a Codex account and connect to github.

@brow
brow marked this pull request as ready for review July 19, 2026 19:58
@brow
brow enabled auto-merge (squash) July 19, 2026 19:58
@brow
brow merged commit b1ef791 into main Jul 19, 2026
25 checks passed
@brow
brow deleted the mobile-release/0.4.7 branch 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant