The free board shows a subject's name, not its primary key - #258
Merged
Conversation
An extension that ships no frontend gets the generic board and subject page for free, and both titled a subject with summary.id — an integer for a row-backed subject. inbox-manager's board read "1", "2", "3". The subject already knew better: both bases carry a label, and every app that has a name for its subject overrides get_label. SubjectSummary carries it now. from_attributes means model_validate(self) picks it up with no app change, which is every implementation across both repos except review's, which builds its summary by hand — one line. Required, not defaulted. A hand-built summary that forgets it raises on its board route, which is the loud version; defaulting to "" would title every row with nothing and say so nowhere. Two test fixtures and two wire-shape assertions needed updating, which is the contract change showing up exactly where it should. The detail page's first fact was "id"; it is now the subject type in words — "pull request: owner/repo#7" rather than "id: owner/repo#7". summaryEntries skips label the way it already skipped id, so the title never repeats itself among the facts.
label was required but ``str``, so an empty one passed. That is the exact failure required was chosen to prevent: inbox-manager titles a thread with its subject_line, and an email with no subject stores "" — a board of blank rows, saying nothing anywhere about why. SubjectLabel strips and rejects blank, following NonBlank in mcp/schemas.py.
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
1 participant
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.
An extension that ships no frontend gets the generic board and subject page for
free, and both titled a subject with
summary.id— an integer for a row-backedsubject. inbox-manager's board read
1,2,3. The subject already knewbetter: both bases carry a
label, and every app that has a name for its subjectoverrides
get_label.SubjectSummarycarries it now.from_attributesmeansmodel_validate(self)picks it up with no app change — that is every implementation across druks and
druks-apps except
review's, which builds its summary by hand, so one line.Required, not defaulted. A hand-built summary that forgets it raises on its board
route, which is the loud version; defaulting to
""would title every row withnothing and say so nowhere.
The detail page's first fact was
id; it is now the subject type in words —pull request: owner/repo#7rather thanid: owner/repo#7.summaryEntriesskips
labelthe way it already skippedid, so the title never repeats itselfamong the facts.
inbox-manager, which ships no frontend at all, gets a readable board on the next
deploy with no app change.
Closes ENG-849.
🤖 Generated with Claude Code