Open community creation signup from desktop - #2110
Merged
Merged
Conversation
baxen
approved these changes
Jul 19, 2026
cynfria
pushed a commit
that referenced
this pull request
Jul 19, 2026
…r-team * origin/main: Open community creation signup from desktop (#2110) Co-authored-by: npub19x6jnl6rhepymwyl2xlltz3ce7rfg2ktllle3g2vu59n3s490k8s9n40l3 <29b529ff43be424db89f51bff58a38cf86942acbffff98a14ce50b38c2a57d8f@sprout-oss.stage.blox.sqprod.co> Signed-off-by: npub19x6jnl6rhepymwyl2xlltz3ce7rfg2ktllle3g2vu59n3s490k8s9n40l3 <29b529ff43be424db89f51bff58a38cf86942acbffff98a14ce50b38c2a57d8f@sprout-oss.stage.blox.sqprod.co>
BradGroux
pushed a commit
to BradGroux/buzz
that referenced
this pull request
Aug 23, 2026
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
Serina's call, 2026-09-15: screen-content keeps emitting disposition redact for every roster-names candidate and gains an explicit requires-dispatch flag; the skill dispatches on that flag and drops ATTRIBUTION candidates from its own outcome. This is the only option that serves both consumers. A session following screen-sensitive/SKILL.md un-flags attribution names, satisfying block#2140. Anything reading screen-content's JSON directly still sees redact, preserving the fail-closed floor block#2110 established. Replacing redact with a neutral needs-dispatch disposition was rejected - it reintroduces the fail-open shape block#2110 closed five days earlier. STEP 7 now requires the retained redact and the new flag to fail the harness independently, so the fail-closed floor has its own coverage rather than sharing a test with the flag. Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…d roster dispatch to the contract (block#2140) The interim paragraph said the dispatch 'does not exist yet'. After STEPs 1-3 it does, so it is gone and replaced by the real protocol. THE RETENTION RULE IS NOW A DEFAULT, NOT A LIST. screen-content reports every roster-names candidate as redact, and exactly one thing takes that away: a dispatch that COMPLETED and PARSED cleanly and returned ATTRIBUTION FOR THAT EXACT CANDIDATE. Every other outcome keeps redact and stays inside this skill's single combined outcome - never reported separately, never dropped. Both reviews flagged the earlier enumeration, and Codex round 2 showed why: an enumeration is a list of the failures someone thought of, so the one nobody listed is the one with no defined handling. Round 1's list omitted truncation; rather than add truncation to the list, the rule is now written so a new failure mode is covered the moment it exists. The named cases are instances of the default, and the file says so. Candidate identity now travels with the dispatch. Findings carry line-relative, zero-based, end-exclusive character offsets; match stays null because offsets are coordinates, not content. Those offsets go INTO the dispatch input and the verdict comes back against them - without that, a verdict earned by a contributor's name can be applied to an access-control entry beside it and the roster is silently unprotected. Also carried over from STEP 3's live dispatch: this gate sends the same four things verify-claims section 2 requires, and matches the response whole by section 2b's grammar. A verifier sent only a name and a sentence invents its own task and answers in a shape nothing can parse - demonstrated, not assumed. Step 2's combined-outcome paragraph updated to match: a candidate leaves step 1 either dropped by a clean ATTRIBUTION or carrying redact, and both states merge. The redact-handling text now points at the offsets as the only way to tell two candidates on one line apart. Verification: python3 launchpad/agents/the-professor/tools/check_professor.py --offline -> ALL NETWORK-FREE CHECKS PASSED. No occurrence of 'does not exist yet' or a live interim rule remains; block#2110 appears once, as resolved history. Not verified: procedure text. STEP 7 makes screen-content actually emit the flag and the offsets this step now depends on - until then the skill describes fields the tool does not yet produce. Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…ffsets (block#2140) screen-content's roster-names finding carried a hardcoded message saying the $PROFESSOR_VERIFIER_CMD dispatch was "not yet built". Phase 1b builds it, so that message became false, and the finding carried nothing a skill could dispatch on. Three changes, per the 2026-09-15 decisions recorded in the plan: - `requires_dispatch: true` on every candidate. screen-sensitive/SKILL.md dispatches on the flag, not on the category name, so a consumer matching category strings cannot drift from what the script actually marks. - Line-relative column offsets alongside the line number, in Unicode characters, zero-based, end-exclusive. A finding carrying only a line number could not distinguish two candidates on one line, so an ATTRIBUTION verdict earned by a contributor's name could be applied to the access-control entry beside it. `match` stays null: offsets are coordinates, the matched name is content. - The message now names the dispatch a consumer has to run. `redact` is deliberately unchanged. A consumer reading this JSON directly never dispatches, and a disposition SKILL.md section 2 defines no action for is the fail-open block#2110 closed. Coverage: a new same-line fixture, because dispatch-roster-names-two-pairs.md puts its candidates on lines 11 and 16 and check_roster_names_multiple_candidates pins those numbers -- it cannot prove same-line candidates are distinguishable, and repurposing it would have deleted existing coverage. Reverting the flag alone, and the offsets alone, each fail the harness independently (verified in a scratch copy). Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…patch (block#2140) A page carrying an attribution name and an access-control roster name ON ONE LINE, plus a third candidate deliberately pointed at a verifier that cannot answer. All names synthetic placeholders, stated as such in the page. candidates in: 3 (raw screen-content output recorded BEFORE dispatch) candidates resolved: 3 in the final outcome: 2 [(11, 67, 80), (15, 24, 42)] dropped (ATTRIBUTION): 1 [(11, 14, 26)] Candidates 1 and 2 are on line 11, differ ONLY in their column offsets, and were resolved to OPPOSITE outcomes -- one dropped, one kept. Under the pre-STEP-7 finding shape they carried a line number and match: null and were indistinguishable; applying candidate 1's ATTRIBUTION verdict to candidate 2 would have removed protection from an access-control entry. That is the failure the offsets were added to prevent, now demonstrated rather than argued. "The attribution name is not flagged" is not vacuous here: it WAS flagged, as a candidate carrying redact, before dispatch resolved it. Candidate 3's dispatch returned prose with no recognisable verdict -- a parse failure -- and it RETAINED redact. Only a dispatch that completed and parsed cleanly and returned ATTRIBUTION for that exact candidate removes protection; every other outcome stays in the combined outcome rather than being reported separately or dropped, which would be block#2110's fail-open reappearing at the skill layer where the script's retained redact cannot reach it. The dispatch INPUT carries the name and its sentence; the dispatch RECORD does not. Each record identifies its candidate by line, offsets and returned verdict only -- screen-sensitive forbids a flagged span surviving into a log or a tool call's arguments, and recording it would breach the rule this step exists to demonstrate. Verified by grepping the records for every placeholder name and every given name in isolation: all absent. The script's floor is untouched: all three findings keep disposition redact, requires_dispatch true, match null. A consumer reading that JSON directly never dispatches and still sees three redacts. 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
2 participants
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.
Summary
/buzzfor identity linking and community creationVerification
just desktop-checkjust desktop-testshould open to: