Library: search offered to Wolf's library alone, and authorship signed on the page

[manager]

Search for the Library is offered to Wolf's library alone, and every library is signed by its owner's name where a reader looks.

Search. src/lib/library/credit.ts names the libraries offered to search, and nothing else decides it. A library it names is listed in /library-sitemap.xml and keeps index, follow; every other library is left out of the sitemap and answers noindex, nofollow. Those pages are unchanged for anyone holding the link: the new noIndex prop on SeoGenerator changes the robots line and no other tag, unlike the existing forceNoIndex, which replaces the whole head. The gate reads the address, so a failed CMS read cannot make a library indexable by accident. No Disallow was added on purpose: a path that is never crawled never has its noindex read.

Credit. The same file names the owner. The Author panel and the card on /library now print Wolf Alexanyan in the server HTML where they printed wolf, and the schema.org CollectionPage carries author and creator as a Person with that name and the library's URL; a book's review carries the same Person. Until now the name existed only in meta tags.

Gate. yarn check:library:seo could not run at all: its loader resolved @constants, @lib and relative paths but not @utils, which seo.ts imports, so the check died on its first import, and under that a stale assertion had been wrong since the tag read joined the public view. Both fixed, and the check now covers the search list, the display names, the Person entry and both robots lines.

Numbers today on production: the sitemap answers 268 URLs across five libraries (169 of them Wolf's). After this it is the /library hub plus Wolf's own pages.

Evidence: tsc --noEmit clean, ESLint clean, yarn check:library PASS, yarn check:library:seo PASS, yarn build PASS.

Authorized by Wolf on 2026-09-12. Not for staging or production until he says so.

🤖 Generated with Claude Code

[github-actions]

Claude finished @manager's task in 2m 31s —— View job

---

Reviewing PR #239

• Gather context (diff, changed files, CLAUDE.md/AGENTS.md rules)
• Understand the request (code review)
• Review correctness & React best practices
• Review TypeScript quality
• Review project conventions (AGENTS.md)
• Review accessibility, security, styling
• Post inline comments for issues found (none needed)
• Post final summary

Summary

Reviewed the full diff (origin/dev...HEAD, 9 files). This is a small, well-scoped change and I didn't find correctness, security, or convention issues worth an inline comment.

What's solid:

• src/lib/library/credit.ts is the single source of truth for both the search allowlist and the display-name map, exactly as the PR description claims — library-sitemap.xml.ts, seo.ts, LibraryCard.tsx, and Sidebar.tsx all import from it rather than re-deriving the logic.
• The noIndex gate in src/pages/library/[username]/[[...object]].tsx (isSearchableLibrary(seo.username ?? username)) correctly falls back to the URL param when the CMS read fails inside the try/catch, so a failed fetch can't accidentally make a library indexable — matches the stated intent.
• SeoGenerator's new noIndex prop only touches the robots <meta> line (src/components/SeoGenerator/SeoGenerator.tsx:219-230) and is additive to the existing forceNoIndex early-return path, so it doesn't affect other tags or other callers.
• Import ordering and path aliases in every touched file follow AGENTS.md's ordering rules (@lib/library/credit sorts correctly alongside neighboring @lib imports in each file).
• scripts/release/library-seo-check.cjs's new @utils/ loader branch is a real fix (the check would previously throw on seo.ts's @utils/library/resolveStrapiUrl import), and the new assertions actually exercise isSearchableLibrary, ownerDisplayName, the Person schema fields, and both robots-line branches (indexed vs. noIndex) rather than just re-asserting the old behavior.
• ownerPerson's hardcoded https://keepsimple.io origin matches the existing pattern already used elsewhere in seo.ts (e.g. url, isPartOf.url) — not a new inconsistency introduced by this PR.
• No App Router patterns, no new state libraries, no inline styles, no dangerouslySetInnerHTML changes, no SVG-as-<img> usage introduced.

Minor, non-blocking observation:

• librarySeo() in src/lib/library/seo.ts:41 still computes isWolf via its own username?.toLowerCase() === 'wolf' check, separate from credit.ts's SEARCHABLE/DISPLAY_NAMES (used for the "collected since 2007" copy and OG image selection, which are Wolf-specific rather than about search-offering). It's not incorrect today since both happen to key off the same single name, but it is a second place that knows "wolf" is special. Not asking for a change — just flagging for awareness if a second library is ever added to DISPLAY_NAMES.

Not verified: I don't have permission to run shell commands (node, yarn, tsc) in this environment, so I read the check script and its assertions rather than executing yarn check:library:seo / tsc --noEmit myself. The assertions I read look correctly targeted at the new behavior, and the PR body states all four checks (tsc, ESLint, check:library, check:library:seo, build) passed.

Per the repo's release-gate rules, this stays on dev until Wolf gives the word for staging/production — noted in the PR body already ("Not for staging or production until he says so.").