Lor: The Ten Thousand Things

← all epics

Workspace dashboard

ops parked

repo: n/a — this workspace (site/, epics/) · updated 2026-08-12

What this is

An extension of the existing public site (public-site-and-comms) into a working surface Kris actually uses day to day: he clicks an epic, kicks off a Claude Code session against it via the task runner, and — over time — nearly all epic work is moved forward by agents rather than by Kris typing into files himself. When an agent hits a real question or a blocker, it surfaces it instead of guessing or stalling silently. Kris’s job becomes: log in, see what’s asking for him, answer it, unblock the agent, and spot-check PoC/deliverable outputs to confirm things are tracking well.

This is an attention-router for a human supervising many agents, not a project-management tool. The distinction matters for every design choice below: Kris is not the one keeping the board up to date — agents are — and the dashboard’s job is to make sure the small number of things that genuinely need him surface immediately, instead of getting lost in a board full of in-progress rows he doesn’t need to look at.

Why it exists

Right now, “check on the project” means reading through epics/*/status.md by hand, or reading a whole conversation transcript. That doesn’t scale past a handful of epics, and it actively works against the goal of letting agents run more of this autonomously — the more epics are agent-driven, the more Kris needs a single place that tells him specifically where his attention is needed, not a full status report he has to triage himself every time.

Design constraints (settled, not open questions)

These aren’t preferences — each one heads off a specific failure mode, so they’re recorded as constraints an implementation must satisfy, not options to reconsider casually.

1. Split read from write

A public, read-only, sanitised view of agent activity is genuinely desirable and safe — “watch a game get built in public by AI agents” is a real asset for the project’s public story (see public-site-and-comms, WHY.md). But the control surface — submitting tasks, editing status, triggering agent runs — must be authenticated and entirely separate from that public view. A static site bundle (which is what site/ builds today) hides nothing: anything shipped to the public build is visible to anyone who looks, so there is no such thing as “client-side-only” gating for the write surface. The write surface needs real server-side auth, which the current static-only site doesn’t have and this epic must add deliberately, not bolt on.

2. Public input must never reach task execution

Not sandboxed, not even in v1. If an agent with repo write access is consuming open-internet text (a public comment, a public form submission) as part of what feeds into a task prompt, that agent is a prompt-injection target — and the realistic failure mode is a hostile commit landing in the repo, not merely wasted compute. So: public suggestions land as content — a form that writes a markdown file, or similar (GitHub Discussions and outside PRs stopped being options when the repos went permanently private, decision 2026-08-04 — see questions/001-repo-visibility.md) — and Kris triages them into epics by hand. No automatic path from “someone typed something on the public site” to “an agent acted on it.” This should only be revisited after observing real public traffic and behaviour, not designed around hypothetically.

3. Files stay canonical

The dashboard reads and writes the same markdown already in the repo (epics/*/overview.md, status.md, and whatever new per-epic files this epic adds — see the data model below). It never becomes a second source of truth sitting next to the files. Consequence: a broken site build must be an inconvenience, not a work stoppage — agents and Kris can both keep working directly in the files with a plain editor if the dashboard itself is down. This is the same principle public-site-and-comms already established for the public content side; this epic extends it to the control side too.

4. Publication default is private, opt-in to publish

Task prompts, agent transcripts, and blocker/question text may routinely contain things Kris doesn’t want made public — an offhand comment, an unfinished thought, something about family, a business detail. The default for anything new must be private, with an explicit action to make a specific thing public. A default of “public unless marked private” would force Kris to self-censor everything he writes to agents, which defeats the point of a low-friction supervision tool.

5. Blocker/question surfacing is the core feature — not task submission

It would be easy to build this backwards: a nice task-submission UI first, blockers as an afterthought. The actual primary user need, per the vision above, is “what needs me, right now?” — so the data model for that has to be designed first, before anything else:

Scope (for when this moves past speccing)

Non-goals

FIRST TASK — BLOCKS EVERYTHING ELSE IN THIS EPIC: secrets audit

No other work in this epic may start until this is done and reviewed by Kris. The dashboard’s entire premise involves more exposure — a public read-only view, an authenticated write surface, potentially opening this repo’s visibility — and none of that is safe to build toward until it’s confirmed the repo is actually clean.

What triggered this

An Android keystore password was handled in plain text in past task-runner sessions and past chats. That’s the immediate concern, but the audit should not be scoped narrowly to just that one password.

Scope of the audit

  1. Search the current working tree of both the lor-workspace repo and the land-of-lor repo for: any .keystore/.jks file, any plaintext password/credential string, any API key or token pattern.
  2. Search the full git history of both repos — not just current HEAD — for the same things. Deleting a file today does not remove it from history; a password committed once and later removed is still sitting in every commit before the removal, retrievable by anyone with clone access. This means the audit has to walk history (git log -p, or a proper secrets-scanning tool run against the full history, not just a working-tree grep) in both repos.
  3. For anything found, report exactly which repo(s) and which commit(s) it’s in — precise enough that rotation and any history-rewrite decision can be made without re-doing the search.

If anything is found

The visibility recommendation this audit gated — SUPERSEDED by decision, 2026-08-04

The recommendation that stood here (make lor-workspace public, keep land-of-lor private) was decided against by Kris on 2026-08-04: all lor repos stay private, permanently as far as current planning goes — the site’s build output is the only public surface. A clean template repo for others to reuse the mechanism may be published someday, but no lor repo will be. Full record: questions/001-repo-visibility.md. Consequence for this epic: everything below that leaned on GitHub Discussions, outside PRs, or a browsable public repo (constraint 2’s intake examples, task 005’s options) now has only the form-to-file style of mechanism available.

Key open questions

Relevant docs

Status

3 backlog2 done

Next: Parked — the /now queue is good enough for now (Kris, 2026-08-12). Pick one of 003-005 when it stops being enough.

Tasks (5)

backlog (3)

done (2)

Answered questions (1)

Ask an agent about this epic

    Also available as raw markdown.