{{ message }}
Repository navigation
Permalink
Checking mergeability…
Don’t worry, you can still create the pull request.
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 3 commits
- 15 files changed
- 1 contributor
Commits on Jul 27, 2026
-
ai(rules[AGENTS]) Describe every class-level name
why: The previous rule required an Attributes section on NamedTuple and dataclass classes. Both its scope and its stated consequence have since proven wrong upstream in gp-sphinx, which renders these docs, and the same reasoning applies here. Scope: autodoc renders one entry per class-level name, whatever shape declares it. TypedDict keys, Enum members, ClassVars, InitVars, plain constants, and nested classes all reach the reference the same way, so enumerating shapes dates faster than stating the principle. Consequence: the old rule said an undescribed field ships as "Alias for field number 0" or as a bare entry. An undescribed ClassVar is now withheld from the reference entirely, so it goes missing rather than rendering empty -- a failure a reader cannot see and a reviewer will not spot in the diff. Styles: three count, and autodoc honors all three -- an Attributes entry, a docstring under the assignment, and a #: comment. Trap: a Parameters section documents the initializer, not the attributes, and leaves every attribute entry rendering bare beneath it. what: - Restate the rule around every class-level name autodoc renders - Name the three accepted styles, preferring Attributes - Warn that Parameters does not describe attributes - Note that an inherited field needs no restatement
-
cli(docs): Document namespace and output fields
why: A typed argparse namespace declares its fields as bare annotations, so every one rendered as a name and a type with no statement of what it does. The flag's own help text is the meaning, and it lived only in the parser. what: - Describe every CLINamespace field in an Attributes section, carrying over the wording of the flag that assigns it - Describe the OutputMode members by what each emitter does in that mode, and the _WindowStatus and _ColorizedLine fields - Note the three namespace fields no subparser defines, which stay unset at runtime
-
workspace(docs): Document builder and option fields
why: The builder's state is annotated but undescribed, and several fields only make sense against the build lifecycle -- when they are assigned, and what reading one before build() gives you. what: - Describe the ClassicWorkspaceBuilder fields, stating for each whether construction or build() assigns it - Describe the workspace option fields and the ColorMode members - Record that session_name is declared but never assigned; the builder reads the name from session_config
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff master...class-variables