#Candidate 1: Personal Site As Publishing Operating System

• Source: /home/krisyotam/src/100x/bloggers/README.md, overview
• Type: position
• Confidence: high
• Kris point: The goal is not to copy Gwern's implementation, but to make a personal site function as infrastructure for research and publishing.
• Abstract: A serious personal site should stop being a decorative portfolio and start behaving like an operating system. The interesting part is not whether it uses Haskell, Next.js, SQLite, or shell scripts. The interesting part is whether the site reduces the cost of collecting, editing, checking, linking, archiving, and publishing ideas.

The right target is a site that gives the author a command surface. Drafts, backlinks, citations, screenshots, feeds, link checks, AI review, and publication hygiene should be ordinary operations, not heroic cleanup rituals.

• Notes: Directly supported by the bloggers README claim that the point is a personal site as research and publishing infrastructure.

#Candidate 2: Annotation-Transclusion As Low-Friction Blogging

• Source: /home/krisyotam/src/100x/gwern.md, Blog System
• Type: workflow
• Confidence: high
• Kris point: Short-form and off-site writing should become first-class site content without forcing every item through the ceremony of a full essay.
• Abstract: The annotation-transclusion model solves a real publishing bottleneck. Some writing is too substantial to disappear into a comment thread, but too small or situational to deserve a full essay scaffold. Treating these pieces as annotations gives them metadata, search, backlinks, and stable pages while keeping the authoring cost low.

The pipeline matters because it makes the default action preservation instead of loss. A comment, note, or short argument can be captured once and later promoted if it proves durable.

• Notes: Based on the described Gwern /blog/ pipeline and its stated motivation.

#Candidate 3: The Blog Post Can Be A Thin Shell

• Source: /home/krisyotam/src/100x/gwern.md, Generated Page Structure
• Type: observation
• Confidence: high
• Kris point: A blog page does not need to own its content if a stable metadata object can be transcluded into it.
• Abstract: The useful separation is between content and publication surface. A generated blog page can be almost empty: frontmatter, canonical link, transclusion marker, and a return link. The durable object is the annotation with ID, author, abstract, and metadata.

That is a different mental model from hand-crafting every post as a separate source file. The post becomes a view over a structured note.

• Notes: Supported by Gwern's generated Markdown page structure.

#Candidate 4: Off-Site Writing Needs A Home Base

• Source: /home/krisyotam/src/100x/gwern.md, Why This Design
• Type: argument
• Confidence: high
• Kris point: Writing posted elsewhere should still be captured, indexed, and made linkable from the author's own site.
• Abstract: The internet encourages writing in other people's boxes: comments, forums, social media, newsletters, chat logs. The loss is not only ownership. The loss is that good fragments become hard to find, hard to cite, and disconnected from the rest of the author's work.

A personal site pipeline should treat off-site writing as importable material. Once captured, it can receive a canonical URL, backlinks, search visibility, and a place in the author's archive.

• Notes: Derived from Gwern's off-site annotation flow and the blogger automation research.

#Candidate 5: AI Co-Authorship Needs Metadata

• Source: /home/krisyotam/src/100x/gwern.md, AI Collaboration Model
• Type: position
• Confidence: high
• Kris point: If AI meaningfully contributes to a work, the model should be credited explicitly in metadata rather than hidden in the process.
• Abstract: AI use should not be an invisible stain or an invisible ghostwriter. If a model contributes materially, the site can say so in the author field. The human remains first because curation, direction, selection, and responsibility remain human.

This is not a slogan about authorship. It is a database convention: Human, Model, Model. That convention makes disclosure cheap and consistent.

• Notes: Supported by Gwern's author field convention and AI co-authored examples.

#Candidate 6: LLMs Are Search, Not Sovereignty

• Source: /home/krisyotam/src/100x/gwern.md, Workflow Pattern
• Type: aphorism
• Confidence: medium
• Kris point: LLM writing workflows are strongest when they generate candidates for human selection, not when they replace authorial judgment.
• Abstract: The useful AI writing loop is generate, rank, select, edit. The model expands the search space. The author supplies taste, purpose, ordering, and final responsibility.

That distinction keeps the workflow honest. A pile of model outputs is not a finished work. It is raw material for curation.

• Notes: Based on the "intensive search + personalization" description in the Gwern analysis.

#Candidate 7: Critical Judgment Is Part Of The Prompt Loop

• Source: /home/krisyotam/src/100x/gwern.md, Workflow Pattern
• Type: workflow
• Confidence: high
• Kris point: The model should be used not only to produce variants, but also to prune weak variants under human supervision.
• Abstract: A writing pipeline should ask models to criticize as well as draft. Generation alone produces volume. Criticism begins to convert volume into signal.

The point is not to trust the model's taste blindly. The point is to turn selection into an explicit stage. Asking several models to generate, then asking for pruning, gives the human editor a sharper field of candidates.

• Notes: Supported by the described Gwern workflow in which LLMs are tested for critical judgment.

#Candidate 8: Cheap Models Can Label The Archive

• Source: /home/krisyotam/src/100x/gwern.md, Cluster Labeling
• Type: workflow
• Confidence: high
• Kris point: Expensive authorial judgment should not be spent naming every automatically discovered cluster.
• Abstract: Once content is embedded and clustered, a cheap model can do the boring naming work. It can read a parent tag, a blacklist of previous labels, and a shuffled set of titles, then propose a small URL-safe label.

This is the right kind of automation: bounded, inspectable, and easy to cache. The model is not deciding what the archive means. It is suggesting handles for clusters the pipeline already found.

• Notes: Based on Gwern's tagguesser.py description.

#Candidate 9: Sort By Magic Is A Second Index

• Source: /home/krisyotam/src/100x/gwern.md, AI Infrastructure
• Type: essay-seed
• Confidence: high
• Kris point: A site should support browsing by semantic similarity in addition to chronology, tags, and manual categories.
• Abstract: Tags and dates are authorial indexes. Search is a user query index. Embedding clusters create a different surface: an emergent index of nearby ideas.

"Sort By Magic" works because it does not replace the older structures. It adds a browsing mode for the moments when the reader does not know the right tag or query. That is valuable on a large personal site where the archive is more than a reverse-chronological feed.

• Notes: Supported by Gwern's embedding, clustering, and directory generation pipeline.

#Candidate 10: Related Posts Should Come From The Corpus

• Source: /home/krisyotam/src/100x/gwern.md, Embedding-Based Related Content
• Type: workflow
• Confidence: high
• Kris point: Related content should be computed from the whole corpus, not hand-maintained one link at a time.
• Abstract: Manual related links are high quality but expensive. They also decay because the author rarely revisits old pages after adding new material. Embeddings give the archive a way to notice new neighbors.

The good shape is not full automation on the page. It is a generated suggestion layer that can be cached, inspected, and exposed where it improves navigation.

• Notes: Based on Gwern's embedding and nearest-neighbor notes.

#Candidate 11: Blog Promotion Should Be A Threshold

• Source: /home/krisyotam/src/100x/gwern.md, Key Constraints
• Type: workflow
• Confidence: medium
• Kris point: The site can use size and metadata thresholds to decide when an annotation deserves a standalone blog surface.
• Abstract: A low-friction writing system still needs gates. Gwern's pipeline uses abstract length, author prefix, URL rules, and IDs to determine what becomes a blog page. That is a useful pattern because it turns promotion into a repeatable rule rather than a mood.

For Kris's site, the precise thresholds can differ. The important idea is that the pipeline should make enough things publishable without making everything a post.

• Notes: Based on the Gwern lengthMin, URL, author, and ID constraints.

#Candidate 12: Recursive Blog Posts Keep The Model General

• Source: /home/krisyotam/src/100x/gwern.md, Recursive Blog Posts
• Type: observation
• Confidence: high
• Kris point: A self-hosted post can use the same annotation machinery as imported off-site writing.
• Abstract: The elegant move is allowing an annotation to point to its own future blog URL. That means the system does not need a separate kind of object for native short posts. The same annotation pipeline handles imported writing and self-hosted writing.

This keeps the model small. Instead of asking "is this a comment or a post?", the site asks whether the metadata qualifies it for a generated surface.

• Notes: Directly supported by the recursive blog post section.

#Candidate 13: A Content Registry Beats Scattered Lists

• Source: /home/krisyotam/src/100x/files/codexAudit.md, Severity 1
• Type: argument
• Confidence: high
• Kris point: Content types should be defined once and consumed everywhere.
• Abstract: A personal site with many content forms cannot afford duplicated lists of types in routing, feeds, search, sitemap, scripts, and SEO. Every duplicated list is a future disagreement.

The registry is not abstraction for its own sake. It is the control plane for the site's content surfaces: table, route, canonical URL mode, sync source, date column, tags, feeds, search, and sitemap inclusion.

• Notes: Based on Codex audit recommendation for a single content registry.

#Candidate 14: Database Roots Are Trust Boundaries

• Source: /home/krisyotam/src/100x/files/codexAudit.md, Database artifact ownership
• Type: argument
• Confidence: high
• Kris point: Scripts and runtime code must agree on one database root or the site will silently drift.
• Abstract: A script that writes one SQLite directory while the app reads another is worse than a failing script. It produces believable but false state. The site looks automated while the automation is operating on the wrong artifact.

The fix is boring and necessary: one database root, one path helper, environment overrides, and failure on core sync errors.

• Notes: Supported by the Codex audit's root data/ versus stale public/data/ problem.

#Candidate 15: Canonical URLs Need One Owner

• Source: /home/krisyotam/src/100x/files/codexAudit.md, Canonical URL behavior
• Type: argument
• Confidence: high
• Kris point: SEO, sitemap, metadata, breadcrumbs, and client links should not rebuild canonical URLs independently.
• Abstract: "Sexy URLs" are a site convention only if every layer agrees. If rewrites, helpers, components, JSON-LD, and sitemap logic each rebuild URLs locally, the convention becomes folklore.

The right pattern is to normalize URLs server-side and pass item.url through shared components. A URL should be data, not a guess repeated in five places.

• Notes: Supported by Codex audit evidence on duplicated canonical URL behavior.

#Candidate 16: Route Trees Should Show Ownership

• Source: /home/krisyotam/src/100x/files/codexAudit.md, App Structure
• Type: position
• Confidence: high
• Kris point: The App Router tree should contain route code, not authored content payloads or unclear group boundaries.
• Abstract: A route tree is a map of application ownership. When content files live inside route folders, or empty route groups linger, the map stops answering the basic question: where does this page belong?

Moving payloads behind loaders and keeping the route tree focused makes the app easier to scan. It also makes later content moves less risky because imports are centralized first.

• Notes: Based on Codex audit sections on src/app content payloads and dead route groups.

#Candidate 17: Client Boundaries Should Be Small Islands

• Source: /home/krisyotam/src/100x/files/codexAudit.md, Client Boundaries
• Type: argument
• Confidence: high
• Kris point: Mostly static layout should not become client-side because one small part is interactive.
• Abstract: A broad "use client" at the top of a shared layout component is a quiet tax. It spreads client boundaries into pages that mostly want server-rendered markup.

The better shape is a server-safe renderer plus narrow interactive islands. The authoring experience stays the same, but the codebase gets a clearer separation between display and browser state.

• Notes: Based on Codex audit discussion of the layout header.

#Candidate 18: Listing Pages Need Shared State Machinery

• Source: /home/krisyotam/src/100x/files/codexAudit.md, Listing clients
• Type: workflow
• Confidence: high
• Kris point: Collection pages should share search, filtering, sorting, and empty-state logic instead of copying it per content type.
• Abstract: Every copied listing client becomes a small fork of product behavior. Search, URL query sync, sorting, category options, and empty states should not be re-decided for every collection.

The fix is to make route clients responsible for data shape and item rendering, while shared hooks and shells own the common mechanics.

• Notes: Supported by Codex audit evidence across content, TIL, Now, scripts, and sequences clients.

#Candidate 19: Tracking Pages Are A Parameterized Problem

• Source: /home/krisyotam/src/100x/files/claudeAudit.md, Copy-Paste Tracking Routes
• Type: workflow
• Confidence: high
• Kris point: Anime, film, TV, manga, and games tracking should be one medium-aware system, not several near-identical pages.
• Abstract: The tracking section is the clearest example of copy-paste architecture. The pages differ mainly by table, field names, and labels. That is exactly the sort of variation a dynamic route and shared browser should absorb.

Consolidating the route, layout, and API would reduce code size and make future behavior changes land once.

• Notes: Supported by both Claude and Codex audits on tracking duplication.

#Candidate 20: The August Target Is Convergence

• Source: /home/krisyotam/src/100x/files/codexAudit.md, Executive Summary
• Type: position
• Confidence: high
• Kris point: The lean-codebase target is mostly about converging parallel sources of truth.
• Abstract: The main structural problem is not one terrible subsystem. It is drift: content types, database paths, canonical URL logic, script paths, client state, and CSS all have parallel owners.

The August target should therefore be convergence. One registry, one database root, one canonical URL resolver, one script path helper, route folders with route code, and shared primitives for listings and tracking.

• Notes: Condenses the Codex audit's highest-value target list.

#Candidate 21: Delete Before You Split

• Source: /home/krisyotam/src/100x/files/claudeAudit.md, Dead Exports and Priority Actions
• Type: aphorism
• Confidence: medium
• Kris point: Removing dead exports is one of the cheapest ways to make a codebase easier to navigate.
• Abstract: Not every cleanup starts with a refactor. Some cleanup starts with deletion. Thirty-one dead exports in lib/ are not a disaster, but they are false affordances: names that look available, documented by existence, but unused by the system.

Deleting dead code shrinks the map before larger work begins. It makes later splitting and consolidation easier because there is less shadow API to preserve.

• Notes: Based on Claude audit's list of dead exports and Tier 1 action.

#Candidate 22: Monoliths Hide Multiple Decisions

• Source: /home/krisyotam/src/100x/files/claudeAudit.md, Monolithic Components
• Type: observation
• Confidence: high
• Kris point: Large files are costly when they combine data fetching, state, rendering, formatting, and interaction decisions.
• Abstract: A 1,500-line component is not merely long. It usually hides several decisions that should be visible: what data is fetched, how it is transformed, what state is local, what is presentation, and what behavior is shared.

Splitting is not about worshiping small files. It is about making the boundaries of responsibility visible enough that changes can be made without reading the whole artifact.

• Notes: Supported by Claude audit examples such as reading.tsx and survey.tsx.

#Candidate 23: Error Boundaries Are Publishing Infrastructure

• Source: /home/krisyotam/src/100x/files/claudeAudit.md, No Error Boundaries
• Type: argument
• Confidence: high
• Kris point: A public personal site should have recovery surfaces for important route groups.
• Abstract: Error boundaries sound like application polish, but on a personal site they are publishing infrastructure. A failed route should not collapse into a generic framework page with no recovery path.

Adding error.tsx files to critical route groups is a small way to make the site more resilient without changing content or design.

• Notes: Based on Claude audit finding of zero App Router error boundaries.

#Candidate 24: Build Flags Can Lie About Safety

• Source: /home/krisyotam/src/100x/files/claudeAudit.md, Build Safety Gaps
• Type: argument
• Confidence: high
• Kris point: A low-memory build that disables type-checking and linting should be treated as a safety exception, not a normal build path.
• Abstract: A successful build is only meaningful if the build checked the things you think it checked. Disabling TypeScript and ESLint may be necessary under memory pressure, but it changes the meaning of green.

The pipeline should make that distinction explicit. A fast or low-memory path can exist, but the quality gate still needs a path that enforces type and lint expectations.

• Notes: Based on Claude audit's build:lowmem warning.

#Candidate 25: Fonts Are Dependencies

• Source: /home/krisyotam/src/100x/files/claudeAudit.md, Font Bloat
• Type: observation
• Confidence: high
• Kris point: Font files should be audited like dependencies because they affect weight, style coherence, and maintenance.
• Abstract: Fonts feel like design assets, but in a static site they are also dependencies. Sixteen megabytes across many families is a codebase smell if nobody can say which families matter.

The audit is not an argument for visual austerity. It is an argument for intentional type. Keep what serves the site, subset what is expensive, and remove ornamental leftovers.

• Notes: Supported by Claude audit font inventory.

#Candidate 26: Private Scripts Do Not Belong In Public

• Source: /home/krisyotam/src/100x/files/codexAudit.md, Scripts and Tooling Shape
• Type: position
• Confidence: high
• Kris point: Browser-delivered scripts and private operational tooling should not share the same public directory.
• Abstract: public/ is a delivery surface. It should not become the home for DB mutators, prose tools, document sync, and commit workflows just because they are scripts.

The migration needs compatibility and documentation, but the target shape is clear: browser assets in public, operational tooling under scripts, and shared helpers for paths.

• Notes: Supported by Codex audit, with caveat that project memory currently fixes public script categories.

#Candidate 27: Style As Code

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Gwern.net patterns
• Type: workflow
• Confidence: high
• Kris point: Citation conventions, URL cleanup, typography, spelling, and metadata normalization can be enforced as code.
• Abstract: Style guides are useful, but style scripts are operational. A personal site can apply global rewrites for URLs, spelling, citation conventions, typography, link cruft, and metadata normalization.

This does not replace editorial judgment. It removes mechanical inconsistency so judgment can focus on argument, structure, and taste.

• Notes: Based on blogger research note "Style as code."

#Candidate 28: The Sync Script As Release Engineer

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Gwern.net patterns
• Type: workflow
• Confidence: high
• Kris point: A serious publish script should do release engineering work, not merely copy files.
• Abstract: The publish path can check dependencies, disk space, process collisions, cleanup, priority, pulls, rewrites, compilation, metadata, backlinks, sitemap, link checks, and upload. That sounds excessive only if the site is treated as a folder of pages.

If the site is infrastructure, the sync script is the release engineer. It should refuse fragile states before they reach production.

• Notes: Based on Gwern sync script patterns in blogger research.

#Candidate 29: Link Extraction Is An Archive Queue

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Gwern.net patterns
• Type: workflow
• Confidence: high
• Kris point: External links should be extracted into an archive queue before publication.
• Abstract: Link preservation gets easier when extraction is separate from archiving. First gather every external URL with source references. Then deduplicate, archive, check, and report.

This turns link rot from a future embarrassment into a current pipeline stage. The author does not need to remember which links matter because the corpus produces the queue.

• Notes: Supported by Gwern-inspired archive queue commands in research and toolbelt notes.

#Candidate 30: Archive Before You Publish

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Gwern.net and Cross-Cutting Ideas
• Type: aphorism
• Confidence: high
• Kris point: Important external references should be saved locally before the page depending on them goes live.
• Abstract: A link is not a citation if it silently disappears. For a long-lived personal site, publication should include an archiving pass for external references.

The practical version is not complicated: extract links, save them with stable paths, handle PDFs specially, and keep enough metadata to recover what the page meant at publication time.

• Notes: Based on Gwern's preemptive link archiving pattern.

#Candidate 31: AI Review Should Be Auditable

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Robin Sloan
• Type: position
• Confidence: high
• Kris point: AI revision loops should preserve plans and revisions so model influence remains inspectable.
• Abstract: The danger in AI-assisted revision is not only bad prose. It is invisible process. If a model proposes a plan, applies edits, and overwrites the draft, the author loses the ability to inspect what happened.

The better loop saves the first plan, saves each revision, and lets the human compare. Auditable AI is slower than blind acceptance, but it keeps authorship legible.

• Notes: Supported by Robin Sloan pattern in blogger research.

#Candidate 32: Separate Revision Planning From Revision Application

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Robin Sloan
• Type: workflow
• Confidence: high
• Kris point: A model should first propose a revision plan, then apply changes only after that plan can be evaluated.
• Abstract: "Revise this" is too blunt for serious prose. Asking for a plan first forces the model to expose its intended interpretation of the draft's weaknesses.

Only after that should the application step run. This keeps the author in the loop at the point where judgment matters most: deciding which diagnosis deserves an edit.

• Notes: Directly based on the Sloan workflow note.

#Candidate 33: Reusable AI Prompts Beat Pasted One-Offs

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Simon Willison
• Type: workflow
• Confidence: high
• Kris point: AI assistance should be exposed through named command-line templates and fragments, not ad hoc prompt paste.
• Abstract: A prompt pasted once is a mood. A saved template is tooling. When AI review lives in named commands, it can be reused, improved, compared, and taught to other parts of the pipeline.

This is especially important for draft review. "Find weak claims and missing sources" should be a stable operation, not a new incantation every time.

• Notes: Based on Simon Willison patterns and toolbelt AI review commands.

#Candidate 34: AI As Skeptical Editor, Not Silent Author

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Cross-Cutting Ideas and Tom MacWright
• Type: position
• Confidence: high
• Kris point: AI should review drafts for weak claims, missing evidence, and structure problems rather than silently authoring prose.
• Abstract: The cleanest AI role in a writing pipeline is skeptical editor. It can flag weak claims, missing sources, stale assertions, structure problems, and unclear transitions.

That role preserves the author's voice and responsibility. It also produces useful artifacts: review notes, not unattributed generated copy.

• Notes: Supported by blog-ai-review purpose and MacWright's AI disclosure pattern.

#Candidate 35: AI Disclosure Is Interface Design

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Tom MacWright and Derek Sivers
• Type: position
• Confidence: medium
• Kris point: If AI is part of the writing pipeline, the site should make that policy visible.
• Abstract: AI disclosure should not be improvised per post. It belongs in the site's interface and metadata conventions. The reader should know whether AI is absent, used for review, or credited as a contributor.

Different authors can choose different policies. The important thing is that the policy be legible and enforced by the pipeline rather than left as vibes.

• Notes: Combines MacWright's disclosure note with Sivers's anti-AI disclosure example.

#Candidate 36: Draft Status Is A First-Class Field

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Andy Matuschak and Maggie Appleton
• Type: workflow
• Confidence: high
• Kris point: Notes and drafts need maturity states beyond published versus unpublished.
• Abstract: A working archive needs more than a binary switch. Seed, rough, growing, evergreen, archived, private, or abandoned are not cosmetic labels. They tell the author and reader how to interpret the text.

Once status is metadata, scripts can index it, filters can expose it, and the site can avoid pretending that every public note is a finished essay.

• Notes: Supported by Matuschak, Appleton, and /home/krisyotam/src/100x/tasks.md rating revision labels.

#Candidate 37: Public Working Memory Is Not A Failed Essay

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Andy Matuschak
• Type: essay-seed
• Confidence: high
• Kris point: Notes can be public working memory rather than unfinished articles.
• Abstract: Chronological blogging pushes the author toward completed objects. A note system can expose work in progress without apologizing for it, as long as status, links, and revision are explicit.

That changes the function of the site. It becomes a place where ideas are developed, not merely announced.

• Notes: Based on Matuschak patterns in blogger research.

#Candidate 38: Flat Notes Plus Frontmatter Is A Grep Workflow

• Source: /home/krisyotam/src/100x/note.md, slipbox revision
• Type: workflow
• Confidence: medium
• Kris point: Simplifying the note repo into a flat plaintext directory shifts organization into frontmatter and search.
• Abstract: A flat slipbox is a bet on metadata and grep. Instead of encoding too much hierarchy in directories, notes carry title, slug, created and modified dates, backlinks, linked notes, tags, and format.

That makes organization explicit and movable. The file tree stays boring while the note graph, formats, and indexes do the real work.

• Notes: Source is rough planning prose with typos, but the direction is clear.

#Candidate 39: Random Slugs Decouple Identity From Title

• Source: /home/krisyotam/src/100x/note.md, Templates
• Type: observation
• Confidence: medium
• Kris point: Notes can use opaque slugs so titles can change without breaking identity.
• Abstract: Title-derived slugs are readable, but they tie identity to wording. For notes that will be revised, merged, retitled, or reframed, an opaque slug can be more durable.

This is especially plausible for paper notes, person notes, question notes, letters, and lectures where the metadata already gives the human-readable label.

• Notes: Inferred from the random slug examples in slipbox templates.

#Candidate 40: The Corpus Should Produce The Prompt

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Simon Willison and Cross-Cutting Ideas
• Type: workflow
• Confidence: high
• Kris point: Selected files should be bundled into clean model context through tooling instead of manually pasted.
• Abstract: AI-chat workflows get better when the corpus itself can produce a prompt. A command can select Markdown and MDX files, bundle them with paths, and hand the result to an LLM for stale claims, missing sources, or structure review.

This turns chat from a blank box into an interface over the author's own archive.

• Notes: Based on files-to-prompt and spec-print patterns.

#Candidate 41: Golden Pages Make Site Refactors Less Mystical

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Gwern.net patterns
• Type: workflow
• Confidence: high
• Kris point: Known stress-test pages should be rendered and diffed so refactors show concrete output changes.
• Abstract: A personal site with complex typography, annotations, citations, and media needs regression pages. Choose pages that stress the system, render them, strip unstable cache-busting details, and diff against snapshots.

That gives refactors a visual and structural test surface. The author can change internals without guessing whether the published archive shifted.

• Notes: Supported by the Gwern-inspired golden regression pages pattern.

#Candidate 42: Screenshot Automation Is Publishing Evidence

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Simon Willison and Toolbelt
• Type: workflow
• Confidence: high
• Kris point: Screenshots after deploys can preserve visual states and catch layout regressions.
• Abstract: Screenshots are not only for marketing pages. They are evidence of how a site looked after a deploy. Capturing important surfaces gives the author a cheap visual archive.

For a personal site with many page types, screenshot automation complements link checks and build checks. It catches failures that compilers will never see.

• Notes: Based on shot-scraper and blog-screenshot patterns.

#Candidate 43: Future Dates Should Fail Closed

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Xe Iaso and Cross-Cutting Ideas
• Type: workflow
• Confidence: high
• Kris point: Scheduled posts should be blocked unless the pipeline receives an explicit allowance.
• Abstract: Future-dated content is easy to publish accidentally and hard to notice afterward. A small guard can block the mistake unless the author deliberately marks the publish path as allowed.

This is the right kind of publishing check: cheap, deterministic, and targeted at a real class of embarrassing errors.

• Notes: Supported by Xe Iaso pattern and blog-future-dates tooling.

#Candidate 44: Frontmatter Is A Contract

• Source: /home/krisyotam/src/100x/bloggers/resources/toolbelt.md, Metadata Hygiene
• Type: workflow
• Confidence: high
• Kris point: Required frontmatter fields should be checked by tooling, not remembered manually.
• Abstract: Frontmatter is not decoration. It is the contract between prose and the publishing system. Title, date, status, tags, and related fields determine routes, feeds, indexes, and reader expectations.

That means missing fields should fail fast. A site that depends on metadata needs metadata hygiene as a normal build step.

• Notes: Supported by blog-frontmatter and required field patterns.

#Candidate 45: Linkrot Repair Should Be A Patch

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Tom MacWright
• Type: workflow
• Confidence: high
• Kris point: Linkrot repair should produce reviewable diffs instead of silent rewrites.
• Abstract: Automated link repair is useful, but silent mutation is dangerous. Upgrading HTTP to HTTPS, finding archive captures, and replacing broken URLs should leave a patch the author can inspect.

The site gets automation without surrendering editorial control. That is the general rule for prose tooling: propose concrete changes, preserve review.

• Notes: Based on MacWright and notfoundbot pattern.

#Candidate 46: Publish Structured Data As A Site Surface

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Simon Willison
• Type: position
• Confidence: high
• Kris point: The site's databases can be public artifacts, not just hidden implementation details.
• Abstract: A personal site backed by structured data can expose that data directly. Searchable, filterable tables and APIs turn the archive into something readers and tools can inspect.

This does not mean every private implementation table should be public. It means the public corpus can have a data surface beside the prose surface.

• Notes: Based on Simon Willison and Datasette patterns.

#Candidate 47: Many Feeds Respect Many Reading Modes

• Source: /home/krisyotam/src/100x/bloggers/resources/research.md, Simon Willison
• Type: observation
• Confidence: high
• Kris point: A large personal site should offer feeds by content shape, tag, series, or quotation type rather than only one global feed.
• Abstract: One RSS feed treats the site as one stream. A large personal archive is not one stream. It has posts, links, quotations, long essays, series, tags, notes, and other surfaces.

Multiple feeds let readers subscribe to the slice they actually want. That is a reader-interface improvement and a metadata discipline.

• Notes: Supported by Simon Willison pattern in blogger research.

#Candidate 48: Author Tools Should Measure Prose Mechanically

• Source: /home/krisyotam/src/100x/author/README.md, bin and functions
• Type: workflow
• Confidence: high
• Kris point: Sentence length, passive voice, duplicate words, weasel words, readability, and repeated phrases can be checked mechanically before human revision.
• Abstract: Prose tools should not pretend to know what the essay means. They can still catch mechanical issues: duplicate adjacent words, passive constructions, weasel words, overused phrases, long sentences, readability spikes, and TK markers.

That makes the authorial pass cleaner. The machine handles obvious texture problems; the writer handles argument and rhythm.

• Notes: Supported by listed author scripts and functions.

#Candidate 49: Word Count Is Operational Data

• Source: /home/krisyotam/src/100x/author/README.md, Writing Sessions
• Type: observation
• Confidence: high
• Kris point: Writing progress should be tracked with the same seriousness as build or test progress.
• Abstract: Word count is not literary quality, but it is operational data. Daily logs, manuscript snapshots, deadline calculators, sprint timers, and scene statistics make writing visible as work.

For a large writing system, this matters because momentum is otherwise anecdotal. The pipeline should know what changed, when, and by how much.

• Notes: Based on wordlog, nanowrimo, sprint, deadline, and scenestats tools.

#Candidate 50: AI-Chat Posts Need A Candidate Mine

• Source: /home/krisyotam/src/100x/gwern.md; /home/krisyotam/src/100x/files/claudeAudit.md; /home/krisyotam/src/100x/files/codexAudit.md; /home/krisyotam/src/100x/bloggers/resources/research.md
• Type: workflow
• Confidence: medium
• Kris point: Planning notes and structural audits can be mined into short candidate abstracts before any post is drafted.
• Abstract: The audit notes already contain arguments: one registry, one database root, AI as review, archives before publication, site as operating system, annotations as blog substrate, and status as metadata. Mining them into compact candidates gives the writing pipeline a staging area before final prose.

The candidate file is not publication. It is a review surface: title, source, type, confidence, cleaned point, abstract, and uncertainty. That format lets Kris choose which ideas deserve AI-chat treatment without inventing new arguments during extraction.

• Notes: Inferred from the present task and the structure of the supplied source notes.