#Candidate 1: One Image Component

• Source: a1666253-c5c3-4287-9f0b-bb40b6b04ce2.jsonl, 2026-05-23T08:33:19.311Z
• Type: position
• Confidence: high
• Kris point: A site should have one canonical image component, with client code limited to progressive enhancement for the modal.
• Abstract: Image handling is too important to scatter across near-duplicate components. If the site needs captions, modals, comments, and rich formatting, those features should converge into one component rather than a set of competing partial implementations.

The default should remain static and server-side. Client-side behavior is acceptable only where it earns its place, such as progressive enhancement for a lightbox or modal.

• Notes: Directly based on Kris rejecting a separate image.tsx unless it is absorbed by the main component.

#Candidate 2: Vendor Only When It Means Less

• Source: 08e141ed-ab9b-40b4-90cd-d5d85db85492.jsonl, 2026-05-23T08:29:06.860Z
• Type: argument
• Confidence: high
• Kris point: Vendoring a dependency only makes sense if it can be made meaningfully more suckless.
• Abstract: Vendoring is not automatically virtuous. Copying a famous component into the codebase is justified only if the result is smaller, clearer, easier to control, and better aligned with the site.

The question is not whether external code can be owned locally. The question is whether local ownership reduces complexity enough to matter.

• Notes: Based on request to evaluate Yet Another React Lightbox for a smaller vendored version.

#Candidate 3: Images Are Core Infrastructure

• Source: a1666253-c5c3-4287-9f0b-bb40b6b04ce2.jsonl, 2026-05-23T08:26:30.304Z
• Type: position
• Confidence: high
• Kris point: Images are central to krisyotam.com, so image infrastructure deserves special scrutiny.
• Abstract: Images are not decorative extras on the site. They are part of the reading system, the archive, and the way notes, comments, and media become usable.

Because images carry that much weight, the tooling around them should be durable and inspectable. A dependency can be acceptable, but the cost and control surface have to be understood first.

• Notes: Directly based on "images are very important to krisyotam.com."

#Candidate 4: Explain The Ecosystem, Not The Buzzword

• Source: a1666253-c5c3-4287-9f0b-bb40b6b04ce2.jsonl, 2026-05-23T08:24:06.992Z
• Type: workflow
• Confidence: high
• Kris point: When recommending software, explain the actual capabilities instead of hiding behind phrases like plugin ecosystem.
• Abstract: A recommendation is useless if it names a library but does not say what it gives me. "Plugin ecosystem" is not an explanation. It has to cash out into features, constraints, maintenance costs, and reasons the tool is better than the simpler alternatives.

Good technical advice should make the tradeoff legible enough that I can decide.

• Notes: Cleaned from Kris asking for a more verbose explanation of Yet Another React Lightbox.

#Candidate 5: Learn From Gwern, Then Adapt

• Source: 47bd9bf7-4c11-4119-8a55-821a94ceca88.jsonl, 2026-05-23T06:52:21.210Z
• Type: workflow
• Confidence: high
• Kris point: Study Gwern's workflow seriously, then adapt the parts that fit a more suckless personal site.
• Abstract: Gwern's site is worth studying not as a thing to imitate blindly, but as a mature operating model for publishing, indexing, annotation, and AI-assisted surface area.

The point is to extract patterns. If a workflow produces useful index pages, AI-authored summaries, or better navigation, it should be understood at the infrastructure level and then translated into my own system.

• Notes: Based on Kris asking for "next level analysis" of gwern.net and its infra.

#Candidate 6: Focus Before Adopting Everything

• Source: 47bd9bf7-4c11-4119-8a55-821a94ceca88.jsonl, 2026-05-23T06:59:32.981Z
• Type: workflow
• Confidence: high
• Kris point: Even when a system is attractive enough to adopt broadly, start by understanding one focused page or workflow.
• Abstract: Wanting to adopt a lot from another site is not the same as copying it all at once. The useful move is to narrow the target first and understand one page deeply.

The blog page matters because it appears to combine human work with LLM-generated summaries of off-platform work. That mechanism is more valuable than a superficial clone.

• Notes: Directly based on Kris saying he wanted to adopt it all but focus first on Gwern's /blog.

#Candidate 7: AI Conversations Can Become Posts

• Source: 47bd9bf7-4c11-4119-8a55-821a94ceca88.jsonl, 2026-05-23T07:21:20.215Z
• Type: essay-seed
• Confidence: high
• Kris point: AI conversations need a publishing format that acknowledges their origin without treating them like ordinary blog posts.
• Abstract: Some posts begin as conversations with agents. They are not quite essays, not quite blog entries, and not mere transcripts.

The format should preserve the fact that the source was an AI conversation while still giving the result a place in the publishing system. A site needs names and routes that can hold this new kind of work without pretending it is old media.

• Notes: Based on Kris asking what to call AI conversations that turn into posts.

#Candidate 8: Names Should Be Suckless

• Source: 47bd9bf7-4c11-4119-8a55-821a94ceca88.jsonl, 2026-05-23T07:17:17.682Z
• Type: aphorism
• Confidence: high
• Kris point: A name should be simple and concise before it tries to sound literary.
• Abstract: Naming can drift into abstraction fast. "Dispatches" may sound good, but if the direction is suckless, the name has to be short, plain, and durable.

Good names are not just aesthetic. They determine whether a system feels usable every day.

• Notes: Directly based on Kris rejecting a longer name in favor of concise naming.

#Candidate 9: Do Not Over-Academicize

• Source: 47bd9bf7-4c11-4119-8a55-821a94ceca88.jsonl, 2026-05-23T07:15:00.720Z
• Type: position
• Confidence: high
• Kris point: Not every publishing category should be named in an academic or abstract register.
• Abstract: A personal publishing system should not inherit academic language just because it contains serious work. Some routes need to be ordinary, direct, and easy to say.

The structure can support scholarship without making every surface feel like a seminar.

• Notes: Based on Kris telling the assistant it was thinking too academically and abstractly.

#Candidate 10: Preserve Turn Integrity

• Source: 819b8e59-7fcb-4b23-814e-9d5cdc633612.jsonl, 2026-05-23T06:38:58.571Z
• Type: position
• Confidence: high
• Kris point: Chat archives should preserve who said what instead of merging turns into a smoother artifact.
• Abstract: When importing a chat, the transcript should keep its structure. The whole point is to know what came from the agent and what came from the user.

Cleaning the format is fine. Collapsing authorship is not. Provenance is part of the content.

• Notes: Directly based on Kris objecting to "merged turns."

#Candidate 11: Research Dumps Need A Home

• Source: 26a8511b-d235-4282-956f-de43df69dcba.jsonl, 2026-05-23T05:54:53.407Z
• Type: workflow
• Confidence: high
• Kris point: Deep research should be sorted into the 100x directory structure instead of left as chat output.
• Abstract: Research becomes useful when it lands somewhere stable. Scripts, aliases, and examples should not stay trapped in a transcript.

The 100x project is a way to turn discovery into a usable library, with categories for CTFs, IRC, competitive programming, and whatever else deserves its own working shelf.

• Notes: Based on Kris asking for research to be organized into src/100x.

#Candidate 12: Build Toolkits By Community

• Source: 26a8511b-d235-4282-956f-de43df69dcba.jsonl, 2026-05-23T05:54:53.407Z
• Type: workflow
• Confidence: high
• Kris point: Useful scripts should be researched by studying the actual habits of specific technical communities.
• Abstract: The best shell functions are not invented in isolation. They come from seeing what HackTheBox players, IRC users, competitive programmers, photographers, and creators actually automate.

A serious toolkit should be built from observed practice across communities, then cleaned and sorted into local conventions.

• Notes: Synthesizes Kris's repeated requests for community-specific alias and script research.

#Candidate 13: Prepare For The Next Puzzle

• Source: b27d6839-396a-4dcf-ad69-ab29169d3a21.jsonl, 2026-05-21T08:23:00.767Z
• Type: essay-seed
• Confidence: high
• Kris point: A serious puzzle toolkit should be ready before the next Cicada-style event appears.
• Abstract: The right time to build capability is before the puzzle returns. When something like Cicada 3301 appears, the advantage goes to people who already have tools for cryptography, OSINT, audio analysis, number theory, forensics, and strange file formats.

The project is not nostalgia. It is a way to turn curiosity into preparedness.

• Notes: Based on Kris reflecting on being young and less technical during Cicada 3301.

#Candidate 14: Security Research Should Start At The Top

• Source: 0710ce04-79a5-4116-957c-815aec947f20.jsonl, 2026-05-23T06:07:05.862Z
• Type: workflow
• Confidence: high
• Kris point: To design a serious home network, start from NSA, Pentagon, and top corporate security guidance.
• Abstract: A home network should not be planned from vibes and router defaults. If the goal is serious security, the research should begin with the most rigorous public guidance available.

That means looking at hardening guides, firewall models, VLANs, VPNs, hardware boundaries, port policy, and monitoring as one system.

• Notes: Directly based on Kris asking for NSA/Pentagon-level security research.

#Candidate 15: Plan 9 Belongs In The Threat Model

• Source: 0710ce04-79a5-4116-957c-815aec947f20.jsonl, 2026-05-23T06:07:05.862Z
• Type: position
• Confidence: high
• Kris point: A Plan 9 cluster on the same network has to be included in network security planning.
• Abstract: Security planning cannot stop at the Linux machines. If a Plan 9 cluster is on the same network, it is part of the environment and part of the threat model.

The unusual systems are exactly the ones that need explicit research, because standard hardening advice may not map cleanly onto them.

• Notes: Based on Kris asking for equivalent security research for his Plan 9 cluster.

#Candidate 16: AI Should Be Callable Infrastructure

• Source: b5064f41-1c65-4501-9443-ce5211fe593a.jsonl, 2026-05-23T05:40:39.585Z
• Type: essay-seed
• Confidence: medium
• Kris point: AI assistance should be reachable by phone when server work needs hands-free or urgent coordination.
• Abstract: A local assistant is more useful if it can participate through the channels that match the situation. When checking on a server or handling infrastructure, a phone call could be a practical interface.

The idea is not novelty for its own sake. It is about making the assistant available where operational work actually happens.

• Notes: Based on Kris asking how Claude could call him or be called for server checks; avoids account details.

#Candidate 17: Report Only Action

• Source: a8439110-9169-4f75-92ef-07c6d5162b2a.jsonl, 2026-05-23T06:00:21.179Z
• Type: workflow
• Confidence: high
• Kris point: Automation reports should skip noise and mention only repositories where action was taken.
• Abstract: A bulk maintenance command should be efficient in both work and reporting. If a repo is already up to date, the report does not need to spend attention on it.

The useful output is the set of changed repos, the sensible commits made, and the pushes completed.

• Notes: Directly based on the recurring dev-push instruction.

#Candidate 18: Commit Local Work Sensibly

• Source: a8439110-9169-4f75-92ef-07c6d5162b2a.jsonl, 2026-05-23T06:00:21.179Z
• Type: workflow
• Confidence: high
• Kris point: When maintaining many repos, uncommitted work should be turned into sensible commits before pushing.
• Abstract: Repository hygiene should be active, not ceremonial. If a repo has meaningful uncommitted changes, commit them with a message that explains the change and push the result.

The goal is not to narrate every clean repository. The goal is to keep owned repositories moving without losing local work.

• Notes: Based on repeated instructions for dev-push.

#Candidate 19: Snippets Should Be Plain URLs With Comments

• Source: 4a71fcb6-41cd-4720-a8c2-7aad4e424821.jsonl, 2026-05-23T02:07:30.928Z
• Type: position
• Confidence: high
• Kris point: A snippets file should be simple, comment-oriented, and stripped of decorative junk.
• Abstract: A snippets file is useful when each line is easy to scan and reuse. For URLs, the structure should be the URL plus a comment that explains why it is there.

Color-code clutter and overbuilt formatting defeat the purpose. The file should behave like a practical personal index.

• Notes: Based on Kris asking to rewrite snippets with URL plus comment format and remove unrelated material.

#Candidate 20: A Dev Server Script Should Know The Project

• Source: 4a71fcb6-41cd-4720-a8c2-7aad4e424821.jsonl, 2026-05-23T04:40:48.546Z
• Type: workflow
• Confidence: high
• Kris point: A single srv command should handle common project types, including Plan 9, static sites, Next.js, and SvelteKit.
• Abstract: Starting local projects should not require remembering a different command for every stack. A system-level srv script should inspect the project and do the obvious thing.

The script should understand local conventions, not just one framework. It should work from the surrounding directory structure and make the common path short.

• Notes: Directly based on Kris asking to turn srv into a bin script with multiple project types.

#Candidate 21: Ports Should Fail Forward

• Source: 4a71fcb6-41cd-4720-a8c2-7aad4e424821.jsonl, 2026-05-23T04:44:35.789Z
• Type: aphorism
• Confidence: high
• Kris point: A local server command should move to the next available port when the requested one is busy.
• Abstract: A dev server that crashes because port 3000 is taken is not smart enough. It should find the next available port and keep going.

This is basic ergonomics. The command should make local work smoother, not force a manual port hunt.

• Notes: Directly based on Kris saying the script should move to the next available port.

#Candidate 22: Do Not Touch The Old Script Yet

• Source: 2c180ee8-6d2c-4448-8e7c-b769fa88f6df.jsonl, 2026-05-23T03:07:36.718Z
• Type: workflow
• Confidence: high
• Kris point: When replacing a script, first recover and build the better version without deleting the old one.
• Abstract: Replacement should be staged. If an old script exists and a better version was discussed elsewhere, recover the better design and build it alongside the old tool.

Deletion can wait. The first job is to preserve function while clarifying which tool should become canonical.

• Notes: Based on Kris telling Claude not to touch dwrite and later to leave old scripts alone.

#Candidate 23: Chat History Is A Development Resource

• Source: 2c180ee8-6d2c-4448-8e7c-b769fa88f6df.jsonl, 2026-05-23T03:08:05.019Z
• Type: observation
• Confidence: high
• Kris point: Previous AI chats can contain implementation decisions worth searching and recovering.
• Abstract: The transcript archive is not just logs. It is a memory of designs, abandoned rewrites, names, and decisions that may not exist anywhere else yet.

When a script or system feels familiar, searching the chats can recover the missing thread and prevent re-solving the same problem badly.

• Notes: Directly based on Kris asking to search chats for a prior conversation.

#Candidate 24: Theme Consistency Beats Experiments

• Source: 6de59c71-aa98-403d-ae6d-c77f3a258189.jsonl, 2026-05-23T03:11:43.826Z
• Type: position
• Confidence: high
• Kris point: Experimental colors should give way to a coherent theme shared across the system.
• Abstract: Trying greens and reds is fine as an experiment, but if the scheme feels wrong, save it and move on.

The better direction is to pull from the existing editor theme so the desktop environment, code editor, and status surfaces feel like one system.

• Notes: Based on Kris asking to save the current Conky scheme and switch to the Zed config colors.

#Candidate 25: Gitroll Complements Blogroll

• Source: a1c5fc5b-f46e-452b-b9cd-5d3a919539d0.jsonl, 2026-05-22T07:55:18.837Z
• Type: essay-seed
• Confidence: high
• Kris point: A personal site should link to people's git homes, not only blogs and channels.
• Abstract: Blogrolls, podrolls, YouTube links, and Twitch links cover only part of how people publish. A lot of the most interesting work lives in git, often outside GitHub.

A gitroll gives that work a first-class place. It treats source code and personal forges as part of the social web.

• Notes: Directly based on Kris asking to create a gitroll with blogroll-like fields.

#Candidate 26: SourceHut Can Be More Canonical

• Source: 17f295c4-cd20-4ede-bdca-81086213be24.jsonl, 2026-05-21T07:33:11.003Z
• Type: position
• Confidence: medium
• Kris point: For some projects, a SourceHut link may be more canonical than a GitHub link.
• Abstract: GitHub is not always the center of a person's work. If someone lives on SourceHut, the SourceHut URL can be the primary link.

The better blogroll or gitroll should be able to include both, while still respecting which forge is actually canonical for that person.

• Notes: Based on Kris saying to upgrade a link to SourceHut because it seemed more canonical.

#Candidate 27: Pages Should Be Separate Repos

• Source: 17f295c4-cd20-4ede-bdca-81086213be24.jsonl, 2026-05-21T00:42:59.330Z
• Type: position
• Confidence: high
• Kris point: Site-connected pages should be separate repos when they are serious enough to matter.
• Abstract: A route attached to the main domain should not automatically become a folder inside the main site. If it is a real project, it deserves its own repository.

Separate repos make ownership, deployment, and project boundaries clearer. Anything less risks becoming clutter.

• Notes: Directly based on Kris saying pages need to be separate repos.

#Candidate 28: Academic Shrine Pages Can Be Playful

• Source: 012e4b5d-34d4-4abb-af6e-25ec6d73de66.jsonl, 2026-05-21T18:49:10.818Z
• Type: position
• Confidence: high
• Kris point: Academic field pages can be shrine-like and playful rather than framed only as serious research.
• Abstract: Not every academic page needs to present itself as formal research. Some pages can say: I do fun things in this field, make programs, collect images, and write around it.

That still belongs on an academic site. It just needs a page form that admits curiosity, play, and personal attachment.

• Notes: Based on Kris describing new academic pages as "shrine type" and less serious than homepage fields.

#Candidate 29: Classical Backgrounds Have Their Place

• Source: 012e4b5d-34d4-4abb-af6e-25ec6d73de66.jsonl, 2026-05-21T18:52:47.604Z
• Type: observation
• Confidence: medium
• Kris point: Design should match the subject, including a classical white treatment for chess.
• Abstract: A page about chess does not need the same visual language as every other page. A classical white background can carry the subject better than a generic theme.

The site should have enough discipline to stay coherent and enough range to let specific subjects breathe.

• Notes: Based on Kris asking for a chess page with a classical white background.

#Candidate 30: Plan 9 Aesthetics Need Accuracy

• Source: c80569d4-47a6-4b3e-9d12-914c8975e1de.jsonl, 2026-05-16T04:21:07.368Z
• Type: position
• Confidence: high
• Kris point: A Plan 9 colorscheme should be researched for accuracy instead of approximated from memory.
• Abstract: If the point is Plan 9, the colors should not be a vague retro palette. They should be researched from real sources and artifacts.

Accuracy matters because the aesthetic is tied to a working environment, not just a look. The details encode a philosophy of interfaces.

• Notes: Directly based on Kris asking for the most accurate Plan 9 colorscheme.

#Candidate 31: Plan 9 Widgets Should Belong To The System

• Source: c80569d4-47a6-4b3e-9d12-914c8975e1de.jsonl, 2026-05-16T04:25:53.551Z
• Type: position
• Confidence: high
• Kris point: Faces and stats should be integrated like system widgets, not awkwardly run on top of a dwm window.
• Abstract: A widget that floats as an ordinary window is not integrated. If faces and stats are part of the desktop, they should live as part of the system surface.

The goal is not merely to run Plan 9 tools, but to understand how they are supposed to be hooked up and displayed.

• Notes: Based on Kris discussing Plan 9 faces and stats.

#Candidate 32: Separate Code And Writing By Command

• Source: af16476b-e8ca-4376-af22-76b7cdd730bc.jsonl, 2026-05-18T08:36:26.643Z
• Type: position
• Confidence: high
• Kris point: write should launch the writing editor config, while the script formerly competing for that name needs a different term.
• Abstract: Names in a toolchain should reflect the primary action. If code opens the code editor config, then write should open the writing config.

A script that interferes with that naming should be renamed, even if it remains useful. Command vocabulary is part of the interface.

• Notes: Directly based on Kris's naming conflict around write.

#Candidate 33: Tome Names The Body Of Work

• Source: af16476b-e8ca-4376-af22-76b7cdd730bc.jsonl, 2026-05-18T08:43:48.800Z
• Type: essay-seed
• Confidence: high
• Kris point: tome is a better name for scripts that manage the body of work.
• Abstract: tome works because it names the body of work rather than the act of writing. It can hold commands like edit, write, and manage without stealing write from the editor config.

The name creates a small language: code for code, write for writing, tome for the corpus.

• Notes: Based on Kris choosing tome and describing it as his body of work.

#Candidate 34: Root Home Should Stay Small

• Source: d1cbb915-2310-414f-b92f-dc127f339416.jsonl, 2026-05-21T11:10:23.090Z
• Type: position
• Confidence: high
• Kris point: The home directory should have as few visible directories as possible, even when the content corpus is large.
• Abstract: A large writing and content system does not have to sprawl across $HOME. The top level should stay small and intentional.

The hard question is where the many markdown-based content directories belong. Hiding them may introduce problems, but leaving them loose makes the home directory worse.

• Notes: Based on Kris planning a new system with minimal home directories.

#Candidate 35: Hidden Corpus Has Costs

• Source: d1cbb915-2310-414f-b92f-dc127f339416.jsonl, 2026-05-21T11:10:23.090Z
• Type: observation
• Confidence: high
• Kris point: Putting a content corpus in a hidden directory may create practical problems despite making $HOME cleaner.
• Abstract: A hidden .corpus directory is tempting because it reduces visual clutter. But hiding the main body of work can interfere with tooling, discoverability, and daily navigation.

The name and placement of the corpus need to serve both cleanliness and actual use.

• Notes: Directly based on Kris questioning .corpus.

#Candidate 36: Fast Tools Should Feel Like nnn

• Source: 96a19e01-a447-4e8d-b6f5-e4ded8b893b5.jsonl, 2026-05-21T11:23:18.919Z
• Type: position
• Confidence: high
• Kris point: Small command-line tools should be fast enough to feel like nnn.
• Abstract: A Bible lookup tool should not feel heavy just because it has a large text behind it. If the data is local, the interface should be instant.

Speed is part of the design. A tool that handles multi-verse pulls and common queries can still follow suckless expectations.

• Notes: Based on Kris asking for a faster KJV tool with nnn-like speed.

#Candidate 37: Suckless Standards Are A Performance Question

• Source: 96a19e01-a447-4e8d-b6f5-e4ded8b893b5.jsonl, 2026-05-21T11:29:31.144Z
• Type: argument
• Confidence: medium
• Kris point: Suckless style is not just aesthetic; it should be tested against speed and simplicity.
• Abstract: Saying a tool follows suckless standards is not enough. The relevant question is whether those standards made the tool smaller, clearer, and faster, or whether they were applied as decoration.

The standard is practical. If it slows the tool down, something has gone wrong.

• Notes: Based on Kris asking whether suckless standards were followed and whether they would make the KJV tool slower.

#Candidate 38: Use AI Plans As Shared s

• Source: ea11a168-78cb-451f-8551-a5a6385cd2e9.jsonl, 2026-05-20T05:36:34.617Z
• Type: workflow
• Confidence: high
• Kris point: Implementation plans should be turned into checklists that multiple agents can use without mixing responsibilities.
• Abstract: A rewrite plan is not useful if it remains prose. It should become a checklist with sections, micro-sections, owners, and clear progress markers.

When Claude and Codex are both working, the file itself should coordinate the work. The plan should prevent duplicated effort and accidental overlap.

• Notes: Based on Kris asking to split responsibility between Claude and Codex in rewrite.md.

#Candidate 39: Update The File, Not The Chat

• Source: ea11a168-78cb-451f-8551-a5a6385cd2e9.jsonl, 2026-05-20T05:38:01.107Z
• Type: aphorism
• Confidence: high
• Kris point: If a plan is meant to coordinate work, update the file instead of explaining it in chat.
• Abstract: Coordination belongs in the artifact that the workers will use. Explaining the checklist in the chat does not help if the actual file stays stale.

The file is the source of truth. Put the plan where the work happens.

• Notes: Directly based on Kris saying "update this in the file."

#Candidate 40: Static First Means Removing API Fetches

• Source: ea11a168-78cb-451f-8551-a5a6385cd2e9.jsonl, 2026-05-20T07:07:55.699Z
• Type: workflow
• Confidence: medium
• Kris point: Client components that fetch internal API routes should be audited for replacement with server-rendered data.
• Abstract: A static-first site should not accumulate internal API fetches by default. If a client component calls /api/..., that is a surface to audit.

Some endpoints may be necessary, but many can be moved into server components or build-time data. The goal is a smaller runtime and a cleaner architecture.

• Notes: Inferred from agent task summary about auditing RSC-replaceable endpoints during Kris-directed rewrite work.

#Candidate 41: Plan 9 Theme Over Solarized

• Source: a6ca464d-851b-4819-95eb-b812d7db0f62.jsonl, 2026-05-20T16:29:49.616Z
• Type: position
• Confidence: high
• Kris point: krisyotam.com should move from a generic Solarized theme toward a Plan 9-inspired theme drawn from local editor colors.
• Abstract: Solarized is familiar, but it is not necessarily the right identity for the site. A Plan 9 theme can make the site feel more like the rest of the system.

The right palette should be drawn from the local Zed and Neovim themes, so the site becomes part of the same visual world.

• Notes: Directly based on Kris asking for a Plan 9 theme for krisyotam.com.

#Candidate 42: Native VS Code Is Refused

• Source: 057f60d0-17f2-4b8c-9bee-bee67e241fa8.jsonl, 2026-05-21T10:56:44.182Z
• Type: position
• Confidence: high
• Kris point: Even when a VS Code-derived feature is useful, native VS Code is not an acceptable tool.
• Abstract: A theme or extension can be worth borrowing, but that does not mean adopting the whole upstream application.

The boundary matters. VSCodium may be acceptable; native VS Code is not.

• Notes: Based on Kris saying he refused to use native VS Code even if possible.

#Candidate 43: Buy Research Capacity Strategically

• Source: 057f60d0-17f2-4b8c-9bee-bee67e241fa8.jsonl, 2026-05-21T10:54:59.055Z
• Type: observation
• Confidence: medium
• Kris point: Different AI subscriptions can be treated as research capacity, not just chat products.
• Abstract: If Gemini offers more deep research under a cheap plan, it can be part of the research stack alongside Codex.

The point is not loyalty to a model. The point is throughput, coverage, and using the right quota pool for the kind of work being done.

• Notes: Based on Kris discussing Gemini CLI and Antigravity as sources of deep research capacity.

#Candidate 44: Small Dashboards Without LazyVim

• Source: 8fb91612-0cb7-4ea1-8903-913eeec22bba.jsonl, 2026-05-21T10:02:10.306Z
• Type: position
• Confidence: high
• Kris point: The useful part of LazyVim can be copied without accepting LazyVim's bloat.
• Abstract: A launch dashboard is useful when code or write opens without a file path. But that does not require adopting LazyVim wholesale.

Borrow the small affordance. Leave the plugin bundle and extra mappings behind.

• Notes: Directly based on Kris requesting only the dashboard behavior and rejecting LazyVim bloat.

#Candidate 45: Dashboards Should Point To The Files That Matter

• Source: 8fb91612-0cb7-4ea1-8903-913eeec22bba.jsonl, 2026-05-21T10:10:34.165Z
• Type: workflow
• Confidence: high
• Kris point: Editor dashboards should surface the configuration files that will actually be edited often.
• Abstract: A start screen is only valuable if it points to real work. For this system, that means mkshrc, planrc, functions, aliases, and the code and writing configs.

The dashboard should be a practical launchpad, not a decorative homepage.

• Notes: Based on Kris replacing LazyVim links with shell and config files he expects to edit.

#Candidate 46: Shell Names Cannot Collide

• Source: c90a2cfa-2420-4f89-ab37-ee353e5b9852.jsonl, 2026-05-21T12:20:13.490Z
• Type: observation
• Confidence: high
• Kris point: Aliases, shell commands, and bin scripts need distinct names because redundant names create confusion.
• Abstract: The shell is a namespace. If an alias, a function, and a bin script fight for the same word, the interface becomes unpredictable.

Tool naming has to be planned like any other API. Short names are powerful because they are scarce.

• Notes: Based on Kris asking whether aliases, shell commands, and bin scripts cannot have redundant names.

#Candidate 47: Make Man Pages For Local Tools

• Source: c90a2cfa-2420-4f89-ab37-ee353e5b9852.jsonl, 2026-05-21T12:17:13.517Z
• Type: workflow
• Confidence: high
• Kris point: Local bin scripts deserve local manual pages.
• Abstract: A personal operating environment can have documentation that behaves like the rest of Unix. If a script is important enough to live in bin, it can have a man page.

This keeps local commands from becoming folklore. The documentation becomes part of the tool.

• Notes: Based on Kris asking if he can create his own man pages for bin scripts.

#Candidate 48: Research Systems Should Be Simpler Than The Dream Version

• Source: c90a2cfa-2420-4f89-ab37-ee353e5b9852.jsonl, 2026-05-21T11:40:52.698Z
• Type: argument
• Confidence: medium
• Kris point: A bloated research-system plan can still contain references worth salvaging, but the replacement should be simpler.
• Abstract: The old research system idea may have had useful pieces, such as bibliography integration, but it became too convoluted to be the main path.

The better move is to keep the references and build a simpler system that can actually be used.

• Notes: Based on Kris describing an older research setup as bloated and convoluted.

#Candidate 49: fs Should Search Repos From Anywhere

• Source: e1b0a562-967b-4cd3-abbc-e014f6ae35ba.jsonl, 2026-05-22T21:46:16.395Z
• Type: workflow
• Confidence: high
• Kris point: A repository search alias should work from anywhere and return a clean list of matching repos under ~/src.
• Abstract: Finding a repo should not require navigating to the source directory first. A small fs command can search root-level directory and file names under ~/src from anywhere.

The output should be formatted for reading, not dumped as raw find noise.

• Notes: Directly based on Kris specifying fs "word" syntax and formatted output.

#Candidate 50: The Source Tree Is src, Not dev

• Source: e1b0a562-967b-4cd3-abbc-e014f6ae35ba.jsonl, 2026-05-22T21:47:10.250Z
• Type: position
• Confidence: high
• Kris point: The working source directory has moved to ~/src, and tooling should stop recreating or depending on ~/dev.
• Abstract: Once the source tree has moved, tools should follow the new canonical path. Recreating a fake dev hierarchy only preserves confusion.

The directory layout is part of the operating system. Scripts need to respect it.

• Notes: Based on Kris telling Claude that src /dev is gone and to use the home src directory.

#Candidate 51: Do Not Create Fake Repo Replicas

• Source: 8c422c44-87ef-493d-8042-68189dca88ba.jsonl, 2026-05-23T01:59:26.704Z
• Type: position
• Confidence: high
• Kris point: Tools should never create fake replica directories when the real repo already exists elsewhere.
• Abstract: A script placed in a fake nested repo path is worse than a missing script. It suggests the assistant did not understand the system.

The right fix is to put tools in the actual system bin or the actual canonical repo, not invent parallel structure.

• Notes: Based on Kris objecting to dev/100x/dev/bin and a fake replica of another repo.

#Candidate 52: The System Bin Is The System Bin

• Source: 8c422c44-87ef-493d-8042-68189dca88ba.jsonl, 2026-05-23T01:59:26.704Z
• Type: aphorism
• Confidence: high
• Kris point: When a script belongs in the system bin directory, putting it in a project-local fake bin is wrong.
• Abstract: A command meant for the whole system belongs where system commands live. Project-local bins are for project-local tooling.

The distinction is simple, but violating it breaks trust in the environment.

• Notes: Based on Kris's criticism of where srv was placed.

#Candidate 53: Plaintext Snippets Are Worth Studying

• Source: be4dd60f-7d04-47b7-aa8e-84ca804d43e9.jsonl, 2026-05-22T22:58:52.591Z
• Type: workflow
• Confidence: high
• Kris point: Before designing a snippets file, study how serious Linux users, developers, writers, and researchers keep theirs.
• Abstract: A snippets file is a personal tool, but it does not have to be designed from scratch. Luke Smith and other power users provide examples of structure, conventions, and useful contents.

The research goal is practical: find real source files, compare them, and decide what to steal or reject.

• Notes: Directly based on Kris's request for deep research on plaintext snippets files.

#Candidate 54: Personal Link Indexes Should Span Domains

• Source: 4a71fcb6-41cd-4720-a8c2-7aad4e424821.jsonl, 2026-05-23T02:07:30.928Z
• Type: observation
• Confidence: medium
• Kris point: A personal snippets index should cover sites, clippings, academia, music, social profiles, code practice, media tracking, wikis, and trackers.
• Abstract: The point of a snippets file is not one category of bookmarks. It is a quick-access map of the places that matter across work, study, media, and maintenance.

The structure should keep categories visible while making individual URLs easy to copy, search, and annotate.

• Notes: Based on the categories Kris pasted for the snippets rewrite; excludes sensitive specifics.

#Candidate 55: Own The Account Surface

• Source: 5707b404-df1d-47b9-8764-bced7ae2e244.jsonl, 2026-05-23T05:12:25.549Z
• Type: workflow
• Confidence: medium
• Kris point: Email-based account discovery should identify every service, transfer, deletion, and expiration across accounts.
• Abstract: Personal account sprawl is an operational surface. A serious audit should find which services were registered with which email, what moved, what expired, and what was deleted.

The output should be organized enough to become a map of exposure and ownership, not just a pile of scanner hits.

• Notes: Based on Kris requesting deep scans across emails; no credentials included.

#Candidate 56: Do Not Lose The Old Reddit Arguments

• Source: 47bd9bf7-4c11-4119-8a55-821a94ceca88.jsonl, 2026-05-23T07:30:23.447Z
• Type: essay-seed
• Confidence: medium
• Kris point: Old platform arguments can become starter content if their text and metadata are recovered carefully.
• Abstract: Old Reddit arguments are not necessarily disposable. They can become seed material for posts if the text is extracted, dates are recovered, and the context is preserved.

The value is not in pretending they were polished essays. The value is in giving them a route where rough public thinking can be archived and worked over.

• Notes: Based on Kris asking to OCR old Reddit argument images for demo posts.

#Candidate 57: Authors Field Must Handle Multiple Origins

• Source: 47bd9bf7-4c11-4119-8a55-821a94ceca88.jsonl, 2026-05-23T07:30:23.447Z
• Type: workflow
• Confidence: low
• Kris point: New post infrastructure should allow multiple authors because AI-assisted and imported work may have mixed origins.
• Abstract: A posts table needs an authors field that can hold more than one author. That matters when content comes from old platforms, conversations, collaborations, or AI-assisted workflows.

The data model should admit mixed provenance instead of forcing every post into a single-author fiction.

• Notes: Based on Kris specifying a posts table with an authors column accepting multiple authors; the mixed-origin rationale is inferred from the surrounding AI-conversation publishing discussion.

#Candidate 58: Media Rollups Need Peer Data

• Source: a1c5fc5b-f46e-452b-b9cd-5d3a919539d0.jsonl, 2026-05-22T07:55:18.837Z
• Type: workflow
• Confidence: high
• Kris point: Linkding can be mined to populate rolls of interesting people and their git profiles.
• Abstract: Personal bookmarks already contain social and technical judgment. If a link database has many people's git profiles, that data should feed the site's public rolls.

The site can become a curated map of people, blogs, and forges by reusing the evidence already collected privately.

• Notes: Based on Kris asking to poll Linkding for git profiles to add to the gitroll.

#Candidate 59: Voice Assistants Need Server Context

• Source: b5064f41-1c65-4501-9443-ce5211fe593a.jsonl, 2026-05-23T05:43:44.233Z
• Type: workflow
• Confidence: medium
• Kris point: A phone-based Claude setup should be evaluated as infrastructure on Stargate, not just as an app.
• Abstract: Running a voice bridge to an AI assistant belongs in the same category as other homelab services. It needs hosting, telephony, credentials, and operational boundaries.

The useful question is what has to be installed or configured on Stargate for it to become a dependable interface.

• Notes: Based on Kris asking what would be required to set up claude-phone on Stargate; no secrets included.

#Candidate 60: Public Research Should Become Markdown

• Source: b8ee3f5e-775f-4096-933b-de647dfa9651.jsonl, 2026-05-21T10:47:40.448Z
• Type: workflow
• Confidence: high
• Kris point: Agent research should end as a markdown file in 100x, not as ephemeral chat text.
• Abstract: When agents research rc shell writing, public video lists, or command collections, the result should be written to a file at the project root.

Markdown is the handoff format. It turns a search session into a reusable reference.

• Notes: Based on Kris telling Claude to write the research into a .md file at the root of dev/100x.