18: Add SiteAccess review labels - #3398
Merged
Merged
Conversation
Flags, in author-facing frontmatter only, every surviving page whose
SiteAccess content still needs a product decision, so a maintainer can
enumerate the outstanding work with one search:
grep -rln '^saas_review:' docs --include='*.md'
Schema (as landed by ticket 13):
saas_review: list of reason values
- siteaccess
- links_removed
saas_review_note: >- one free-text note per page
38 pages now carry `saas_review`; 34 are new here and 4 were already
labelled by ticket 13 (three of those gain the `links_removed` reason and
an extended note). Inclusion rule: a page is labelled when it documents a
SiteAccess-scoped setting or the SiteAccess scoping/matching semantics
themselves; 16 of the 54 pages that merely mention the string are left
unlabelled (a cross-link, a concept definition, the `X-Siteaccess`
request header, a component parameter named `siteaccess`, a deprecated
permission limitation, or a statement that something is *not*
SiteAccess-aware).
`links_removed` (27 pages) records, in the same note, which deleted pages
this page used to link to, so a later pass can check the surrounding
prose.
No SiteAccess content is rewritten and no UI is invented, per the spec's
Out of Scope entry. No page's body changes: every hunk is an addition
inside the leading `---` block, and one page
(`measurementfield.md`) gains a frontmatter block it did not have.
The theme extends Material's `base.html` and has no generic frontmatter
loop, so the keys do not render: after a strict build, `saas_review` and
the note text appear nowhere under `site/`, including `llms.txt` and
`llms-full.txt`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.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
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.
Ticket 18 of the Cohesivo SaaS conversion. Base:
saas-batch-3.A maintainer can list, with one search, every page whose SiteAccess content still
needs a product decision, and read on each one what specifically must be
confirmed. Readers see nothing.
37 files changed, 323 insertions, 0 deletions — every hunk inside the leading
---block.Labels only, proven
The ticket requires that no page's body content change. That was verified
mechanically, not asserted: for all 37 files, the text after the frontmatter
block is byte-identical to
HEAD.Schema
Matches what ticket 13 already landed ahead of this:
List-valued, because pages accumulate more than one reason and a scalar key
would silently overwrite.
Inclusion rule: 38 of 54 pages
Not every page containing "SiteAccess" needs a label. A page is labelled when it
documents a SiteAccess-scoped setting or set-up step (an
ibexa.system.<scope>/ibexa.site_access.config.<scope>/ibexa.siteaccesskey,
siteaccess_group/siteaccess_list, "configurable per SiteAccess") ordefines the SiteAccess scoping and matching semantics themselves.
The 16 excluded are genuine passing mentions — for example
subitems_list.md,where
siteaccessis a component parameter name;rest_requests.md, whereX-Siteaccessis a REST header rather than a delivered setting; andpage_blocks.md/react_app_block.md, whose state configuration is explicitlynot SiteAccess-aware. Labelling those would inflate the maintainer's worklist
with pages that need no decision.
Reason values
siteaccess— 38 pageslinks_removed— 27 pages, each note naming the deleted targetsTicket 13's four pages were extended, not overwritten
Three gained
- links_removedappended to their existing list plus an extraparagraph in the existing note.
configure_translations_management.mdlost nolinks and is byte-unchanged.
One page (
measurementfield.md) had no frontmatter block at all and needed onecreated.
Nothing renders
The theme extends Material's
base.htmlwith no generic frontmatter loop. Provenafter a build:
grep -rl "saas_review" site/→ 0 hits, as are the notephrases, and
site/llms.txt/site/llms-full.txt→ 0. No review banneranywhere.
Maintainer search
Verification
mkdocs build --strict→ exit 0.pytest -q→ 90 passed, no warnings.mkdocs.yml, the invariant test and its baseline all untouched.Two things for the reviewer
Scope call on
links_removed. Repo-wide, 212 pages lost links to deletedcontent; only 39 are in the SiteAccess set. This PR scopes the label to that set,
following the spec's framing of it as a co-reason ("a SiteAccess page that also
lost links to deleted content is the common case"). Read literally, the box would
need ~175 more pages — a separate mechanical pass, and git history already
records every removal. Flag it if you want the literal reading.
Worth knowing for any later link audit: this repo uses the
autolinksplugin, so a bare
foo.mdlink resolves by basename anywhere underdocs/. Anaive relative-path existence check produces false "deleted link" hits; the
detector used here is autolinks-aware.
🤖 Generated with Claude Code