cli

Unfinished Business: Four AI Spirits for Abandoned Code This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine. What I Built A hackathon project can be technically alive and still feel dead. The repository exists. There may even be a half-working feature. But the next decision is fuzzy, the plan changes every hour, and by demo time nobody can say which result was actually observed and which one was only promised. I built Unfinished Business for that gap. It is a local-first workshop around OpenCode. Four small spirits take one project from a vague idea to a proposal, a reviewable plan, one bounded implementation, and an evidence-based review. The point is not to make the agent more autonomous. The point is to make the handoffs harder to fake. OpenCode performs the native work. Entire records the agent sessions and checkpoints behind the project itself. That pairing made provenance part of both the product and the way I built it. Demo - Live interactive example: <unfinished-business-demo.onrender.com> - Source: <kernelKain/unfinished-business> The Render version is a recorded, read-only example. It needs no login and has no model, provider credential, repository, or write access. For a real run, use the local setup below and connect your own OpenCode account. For the fastest judge path: 1. Open the live example. 2. Play the 90-second version. 3. Inspect Architect's approved versions and Witness's evidence. 4. Open the Entire session history to verify how the project was built. Code {% github kernelKain/unfinished-business %} The complete source, local setup, tests, OpenCode integration, and Entire hooks are in the public repository. The four spirits !Oracle, Architect, Maker, and Witness with their responsibilities Each spirit has one job and one stopping point. None of them can approve its own work. Oracle asks the awkward questions first. What is the project actually for? What is known? What is still an assumption? It asks a few questions at a time instead of dropping an intake form on the user. Architect drafts one section of the plan at a time. A revision is shown as a diff. Accepting that draft and approving that exact version are separate actions, so an old approval cannot quietly survive a changed plan. Maker receives a narrow scope only after the current plan is approved. OpenCode still owns the native tools and permission prompts. Clicking “approve” in my interface cannot turn an OpenCode denial into permission. Witness looks at the observed diff and check result in a fresh session. If a run timed out, a check failed, or no live session happened, Witness says that instead of writing a victory paragraph. The characters also change state with the work. Maker can be ready, building, waiting for permission, blocked, or successful; Witness can report evidence or an inconclusive result. Those states are not decoration—they keep failure and uncertainty visible. !Every visual state for Oracle, Architect, Maker, and Witness The complete state sheet used by the interface. A success expression appears only after an observed result. One abandoned project The public example follows Driftwatch, a tiny issue-triage CLI that was left in an awkward state. It reads an issues.json export, but it counts closed issues and calculates staleness from the creation date instead of the latest activity. !The Driftwatch guided sample at the Architect approval step The recorded sample pauses at Architect so a judge can inspect the exact approved plan version before Maker receives work. Oracle narrows the rule. Architect drafts and revises the plan. Maker receives a two-file scope. A recorded Node check passes four behavioral cases. Witness then makes the important distinction: the fixture demonstrates the interface and evidence language, but it is not proof that a live model just made the change. That last sentence matters. I wanted the demo to remain useful even when a provider quota is exhausted, without pretending a recording is a live inference result. How I Built It OpenCode is the engine. It owns model access, the agent loop, tools, permissions, interruption, and native sessions. Unfinished Business owns the workshop around it: idea → Oracle proposal → Architect sections → Maker scope → Witness evidence approve approve exact approve inspect versions There are two deployment paths, and I kept them separate on purpose: !Architecture diagram: the read-only Render demo stops at a recorded fixture, while the full workshop runs locally against the user's own OpenCode server The hosted path stops at a read-only recording. Real model access, approvals, and repository changes remain in the user's local OpenCode environment. The Render path ends at a deterministic, read-only fixture. The local path continues from the browser to the Unfinished Business server, then to the user's own OpenCode server and managed workspace. This is why the public demo can be useful without quietly becoming a shared remote coding environment. Project state is written atomically. Runs are persisted operations with progress, elapsed time, cancellation, retry, and reconciliation controls. A response that arrives after a timeout is validated and applied at most once. The browser never receives a provider API key. In local mode it talks to the Unfinished Business server, which connects to OpenCode on loopback. The only credential the local wizard accepts is the OpenCode server password, held in the application process rather than project data or browser storage. My Agent Session Entire kept the build from becoming another ghost The product is about preserving decisions and evidence, so I wanted the development history to follow the same rule. I used Entire to capture agent-assisted OpenCode sessions as checkpoints connected to the commits they produced. I did not stay in one coding harness for the whole project. Usage limits meant I had to move between OpenCode, Cursor, and Codex. My public Entire session history gave those handoffs one inspectable trail: I could see which session produced a checkpoint, what files it touched, and which commit carried the result instead of trying to reconstruct the previous agent's work from a diff alone. That was most useful when a limit arrived in the middle of a debugging or hardening pass. I could pick up from a concrete checkpoint and commit trail in the next harness while still reviewing what changed and why the earlier session stopped. Entire did not make the tools interchangeable, but it made switching between them much less lossy. This was not a badge added after the build. The repository contains the OpenCode hook integration, git-refs checkpoint configuration, and a preflight check that treats Entire capture as release evidence rather than assuming it is active. Implementation commits carry an Entire-Checkpoint trailer: refactor(demo): say a session was not run instead of NOT_RUN Entire-Checkpoint: 01M6AFB74ZNJM4MXC6K2FAZE5A That link matters when a diff is no longer enough. A maintainer can trace a change back to the agent session and checkpoint that produced it, instead of reverse-engineering intent from the final code. At the time of this write-up, Entire shows 37 checkpoints across 42 commits, covering model integration, platform fixes, Render hardening, documentation, and the recorded demo. Those checkpoints contain 59 recorded messages and about 7.0 million tracked tokens—6.0 million input and 972,500 output—with one development trail merged. The numbers make the practical value clearer: this was a long, multi-harness build, and Entire kept its history inspectable instead of reducing it to one final diff. !Entire session dashboard showing 37 checkpoints across 42 commits, 59 messages, and approximately 7 million tracked tokens The public Entire dashboard captures the scale of the development trail: 37 checkpoints, 42 linked commits, 59 messages, and one merged trail. Entire also exposed a useful failure honestly: later documentation-only commits made while the entire binary was unavailable did not receive a checkpoint trailer. The Git hook reported that and continued without pretending the session had been captured. That is exactly the behavior I wanted for this project—missing evidence stays missing instead of being reconstructed after the fact. Why Does Open Innovation Matter? The project would make much less sense if it were tied to one closed model endpoint. OpenCode gives the user control over the engine. They can connect OpenCode Go, another provider, or a local model, and the workshop discovers the catalog OpenCode actually reports. The workflow does not need to be rewritten when the model changes. That openness is also a boundary. Provider authentication stays in OpenCode. Native permissions stay in OpenCode. A model reply is treated as a proposal, not as authority to approve a section or widen an implementation scope. The public Render deployment uses the same interface without shipping my provider access to every visitor. Judges can understand the product immediately; people who want a real run bring their own OpenCode setup. The Spirit of It The project landed for me when Witness refused to call a recorded fixture a live success. That small refusal captured what I wanted from the whole system. Unfinished projects do not need another agent that confidently invents progress; they need a careful way to recover their intent, finish one bounded piece, and preserve what really happened. What did not fit neatly The hardest part was not generating plan text. It was keeping the state honest when real tools are slow or fail. A model can finish after the HTTP request times out. A permission request can remain pending. A provider can report that a model exists and then reject the request because a quota ended. A revision can make a previously approved section stale. Those are product states now. They do not disappear behind a spinner, and they do not trigger an automatic second native action. The current release also has real limits: - Maker edits an isolated managed workspace, not any repository selected in the browser. - The public site is a preview, not a remote code-execution sandbox. - Windows and Linux ARM64 are not supported. - A spending limit can only use cost OpenCode reports; an unknown-price provider may report that after the request. - The recorded example proves the interface journey, not live inference. Run the real workshop You need Node.js 22.14 or newer and a supported OpenCode 2.x installation. git clone https://github.com/kernelKain/unfinished-business.git cd unfinished-business npm ci In OpenCode, run /connect, choose OpenCode Go or another provider, and confirm a model with /models. Then start the server: npx --no-install opencode serve --hostname 127.0.0.1 --port 4096 In another terminal: npm start Open <127.0.0.1> and use the OpenCode server password in the wizard. Do not paste a provider key into Unfinished Business. Built with - TypeScript, React, Vite, Hono, and Zod - OpenCode through @opencode/client and the pinned cross-platform CLI - Entire CLI with OpenCode hooks and git-ref checkpoints - Atomic JSON project storage - Node's test runner and Playwright - Render for the public read-only preview Prize categories Best Use of Entire — primary category Entire is the development-memory layer behind Unfinished Business. Its OpenCode hooks captured real agent sessions, attached checkpoints to implementation commits, and pushed checkpoint refs separately from the main code history. That gives reviewers something a polished final diff cannot provide: the prompt, agent transcript, touched files, and session context behind a change. It was especially valuable when usage limits pushed me between OpenCode, Cursor, and Codex: the public session history kept the work reviewable across those harness changes instead of splitting the project's development story into disconnected fragments. It also mirrors the product's central idea. Unfinished Business keeps an evidence trail inside the application; Entire keeps an evidence trail for how the application itself was built. Both treat provenance as part of the work rather than a story written afterward. The claim is verifiable in the repository through the hook integration, enabled settings, commit trailers, remote checkpoint refs, and preflight evidence check linked above. Best Use of Render — secondary category Render hosts the no-login interactive front end and recorded workflow while the server independently enforces read-only behavior. It serves the real React and Hono application, rejects mutation routes in hosted-demo mode, and exposes no provider key, repository access, or shared coding environment. That gives judges a useful product tour without pretending the deployment is a public code-execution sandbox. AI assistance and timing I used coding agents while building and reviewing the project. I verified the resulting behavior with automated tests, clean-start checks, and the public demo boundary. The application itself keeps model output behind explicit human approval and native OpenCode permissions.

I can't ask my old team lead why anymore, so I built a séance --- title: "I can't ask my old team lead why anymore, so I built a séance" published: true tags: devchallenge, hf26challenge, opensource, ai cover_image: raw.githubusercontent.com --- This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine. A month ago my team lead left. He was the one who knew why our code is shaped the way it is: why one piece is split from another, why a check lives here and not there, why a decision that looks wrong was actually right. More than once since then I have hit one of those decisions, opened a chat to ask him, and stopped halfway through typing. He has moved on. It felt wrong to pull him back into code he no longer owns, and there was nobody else to ask. git blame did not help. It showed me the last person who touched the file, not the person who decided why it exists. That is when it hit me how much a team loses when one person walks out the door, and how little of what they knew was ever written down where the next person would find it. Halloween is about talking to people who are no longer in the room. So I built a séance for them. > TL;DR > - Ouija Blame asks a line of code why it exists. It walks the line back to the commit that first > wrote it, gathers what its author and reviewers wrote (commits, the pull request, review comments, > linked issues, and the prompts behind agent-written code), and the ghost answers only in their own > words, each one linked. If nobody ever wrote the reason down, the ghost says "I never wrote down why." > - Gemma can only point, then explain with citations. The open model picks passage numbers from a > fixed list, so it cannot put a word in the ghost's mouth, and code checks every quote word for word. Then > it writes a plain-words answer (what the line does, why it exists, what to check before you change it) > where every reason cites a quote by number. > - The test: 45 real lines from Rails, Kubernetes, Home Assistant, Ansible and Istio that someone deleted > as pointless, which broke something and were put back. Every method saw only history from before the > deletion. The séance surfaced a written reason for 28/45 lines; the git blame message, 19/45 > (+20 points, 95% CI +9 to +33). Reading the whole PR behind the blame commit found 29/45, but meant > reading 268 words per line instead of 67. > - What surprised me: no method, mine included, found the reason the line had to come back more than > 18% of the time. The reason code was written and the reason it must stay are usually different, and the > second one is almost never written down. > - What failed: Gemma 4B hates silence. It said "I never wrote down why" for only 1 of the 13 lines where > no method found any reason. What I Built Ouija Blame is a pixel-art séance for one question: *why does this line exist?* It is a séance for people's lost knowledge in a repo, not a haunted terminal. 1. Paste a GitHub link to one line (or open a haunted line from the gallery). 2. The crystal ball wakes up. Behind it, git log -L follows the line back through every change to the commit that first wrote it. git blame stops at the last change, which in my test set was the wrong commit 17 times out of 45. 3. The ghost appears: the person who first wrote the line, with when they were last seen in the repo. They speak in quotes from their commits, PR descriptions and review threads. A reviewer who explained it better appears as another voice in the room. 4. The answer comes first. The medium (Gemma) writes a short card: what the line does, *why it exists* and before you change it. Every reason carries a numbered chip that jumps to the quote it rests on, and a "why" that cites nothing is replaced by code with "the quotes do not state a reason outright". It is labelled as the model's words, never put in the ghost's mouth. 5. The Ouija board is a control, not a decoration. The ghost spells its name with the planchette and slides to YES, or to NO when it has nothing to say. You can take the planchette yourself: rest it on YES to summon, NO to clear, GOODBYE to close the séance, or spell a project (RAILS, KUBE, ISTIO) to call up that project's ghosts. 6. For gallery séances, the page then shows what happened next: the commit that deleted the line, and the revert that brought it back, so you can judge the ghost yourself. !A séance on a Kubernetes storage class: the answer card first, then the ghost and its quotes !A Home Assistant séance: the reason was in a code review comment, not the commit In that Kubernetes example, git blame on cluster/addons/storage-class/openstack/default.yaml shows a group-version bump by a different person. The ghost is @jsafrane, who wrote the file in 2016, and the answer comes from his PR: *"In previous versions of Kubernetes a PersistentVolumeClaim without a StorageClass annotation on these cloud platforms would be satisfied by manually-created PersistentVolume objects…"* Six years later someone deleted it as an OpenStack leftover, and existing Cinder volumes became unusable until it was restored. The ghosts of agent-written code Code written with an AI agent has a new kind of lost knowledge: the prompt. The engineer typed the reason into a chat, and the commit says "Canvas rce2". Entire records those sessions and publishes them next to the code as refs/entire/checkpoints/…. Ouija Blame reads them with plain git (no account needed), so the ghost can quote the human's own prompt: !A séance on agent-written code: the ghost quotes the prompt the developer gave Copilot CLI, recovered from an Entire checkpoint Demo - Live: <ouija-blame.onrender.com>, no login. The gallery opens instantly. A live séance on any public repo under 150 MB takes about a minute (Gemma runs on a small CPU). - Straight to a séance: Kubernetes storage class · Home Assistant Tile · agent-written code - Live séances call GitHub from your browser, so the server holds no GitHub token. GitHub allows each browser 60 calls an hour, about two séances; you can paste your own token, which stays in the tab. Code {% github Tanay3484/ouija-blame %} How I Built It The séance line ──git log -L──▶ every commit that touched it ──▶ PRs · reviews · linked issues · Entire prompts │ passages: exact slices of the raw text (templates, bots, /lgtm dropped) │ BM25 against the line's own words → top 16 ▼ Gemma 3 4B (Ollama): "which passages say WHY?" → ids from an enum │ quote checker: word for word in the source, or dropped ▼ the ghost speaks, or "I never wrote down why." - Code decides, the model reads. The walk, the cutoff, bot and template filtering, ranking and the quote check are plain, tested Python. The model does two jobs a regex cannot: judge *does this paragraph say why?*, then explain the chosen quotes in plain words. - The explanation is cited, and code holds it to that. Citations to quotes that do not exist are stripped; a "why" left with no citation is not shown. Gemma can still over-reach inside a cited answer (one Kubernetes card adds an uncited sentence of interpretation), which is why the quotes sit directly under it. The card runs after the evaluated step, so it changes none of the numbers below. - The model cannot invent a quote. The JSON schema makes passage ids an enum, so Gemma can only choose from what is there, and every chosen passage is checked against its source again before it is shown. Over the 45 test séances the checker dropped 0 passages, which is the point: it is a guarantee, not a filter. - No token on the server. Live séances happen in three calls: the server clones the repo over plain git and walks the line; your browser fetches the PRs and comments from api.github.com; the server asks the medium. The same seance.run() serves the evaluation from a disk cache. - Stack: Python and FastAPI, TypeScript and Vite, all pixel art drawn in code, Gemma 3 4B in Ollama on Render, 31 tests with a git repo built inside the test and a fake model (no network). The evidence The hardest part of "why does this line exist?" is knowing the right answer. Big projects have a natural answer key: reverts of deletions. Someone removes code that looks pointless, it breaks something, and a revert puts it back, usually with a PR explaining why it was needed. - Mining: 96 reverted deletions from local clones of Rails (37), Kubernetes (22), Home Assistant (21), Ansible (11) and Istio (5). For each, the line the deletion removed and the revert restored. - Answer key: I read each revert's message and PR and kept the 45 that state a reason, as one line each. The other 51 just say "This reverts commit X". - Held out by time: every method sees the repo at the deletion's parent, and GitHub comments written at or after the deletion are dropped. The revert is never input. - Four methods: the git blame commit message; blame plus its PR (description, comments, reviews); the five oldest git log -S hits for the line's main identifier; the séance. - Blind grading: all 180 pieces of evidence were shuffled under random ids and graded without knowing the method: does it give the revert's reason (R), some other written reason for the line (E), or no reason (N)? | Method | Gives the revert's reason | Gives a written reason (any) | Words to read (median) | |---|---|---|---| | git blame message | 7/45 (16%) | 19/45 (42%) | 12 | | blame + its whole PR | 7/45 (16%) | 29/45 (64%) | 268 | | git log -S, 5 oldest | 5/45 (11%) | 15/45 (33%) | 41 | | séance | 8/45 (18%) | 28/45 (62%) | 67 | Paired bootstrap over cases, séance minus baseline, any written reason: vs blame +0.20 (+0.09 to +0.33), vs log -S +0.29 (+0.13 to +0.44), vs blame + PR −0.02 (−0.11 to +0.04). On the revert's reason the differences are all within ±0.09 and not significant. So the honest summary: the séance finds a written reason far more often than blame, about as often as reading the entire PR, in a quarter of the reading, and it reaches the original author every time. What went wrong - Gemma does not like to stay silent. It answered "I never wrote down why" in 1 of 45 séances. In the 13 cases where no method found any reason, it stayed silent once. In 16 séances it offered quotes that were real and correctly attributed but did not explain anything, most often a bare commit subject (57% of all quotes were commit messages). The quote checker guarantees the words are real. It cannot guarantee they are relevant. A larger model, or a rule that a bare commit subject never counts as a reason, is the next thing to try, on new cases rather than these 45. - The reason a line must stay is rarely written. Most reverts say "this was still in its deprecation period", "apps still use it", or "CI broke". Those are facts about the world after the line was written. No archaeology of history-before-deletion can find them, which is why every method sits at 11–18% on that column. That is not a bug in the tool. It is the most useful thing I learned: if you know why a line must stay, write it next to the line. - git log -L does not follow code across file moves. In one Rails case the walk stopped at a 2011 commit that moved the code into a new file, so the "ghost" was the person who moved it. - The grader is not independent. Claude graded the 180 items blind to method, and no second person re-graded them. Evidence over 400 words (only the PR baseline) was graded from its opening plus every paragraph sharing words with the answer, a Ctrl-F, which can miss a reason phrased differently. - 45 cases from 5 repos is small. Reverts are a biased sample: code whose reason mattered enough to break something. Every number above comes from python -I scripts/stats.py, which reads only files in results/. Why Does Open Innovation Matter? - The repos that need this most are private. Your team's code and your old lead's PR threads are the last things most companies will send to a closed API. Gemma runs in a container I control, so the same code can run inside your network, next to your Git server, with nothing leaving it. - A séance is all reading. Every séance sends the model thousands of words of other people's writing. On an open model that costs CPU time, not tokens, so the demo can afford to read everything. - I can constrain it as tightly as I want. Ollama's schema-constrained output let me make the model choose from an enum of passage ids, which is what makes "only their own words" a guarantee rather than a prompt instruction. - It will outlive this post. Git, open weights and a public repo: nothing here depends on a service that could change its price or disappear, which feels right for a tool about knowledge that disappeared. The Spirit of It The first real user was me. I opened a haunted line from the gallery, read through the séance, and my honest reaction was: "all I see is a git blame." The quotes were all there, but nothing told me in plain words the one thing I had come for. That sentence changed the product the same night: every séance now opens with an answer card (what the line does, why it exists, what to check before you change it), and every reason on it is pinned to the quote it came from, so you can check the medium against the ghost. The ghosts in the gallery are real people who wrote real code, and most of them simply moved on to other work. Nobody here is framed as dead, the ghost is a generic sprite rather than anyone's photo, and every word it says links to where that person actually wrote it. That last rule turned out to be the whole product: a tool that only lets people speak in their own recorded words is a tool that makes you notice how rarely we write down why. How the work was split This week I was buried in work until the last night, so most of the code was written by Claude Code from specs we agreed on (specs/ in the repo). I chose the idea, the cuts and the evaluation design, and I was its first user. Prize Categories - Best Use of Gemma: Gemma 3 4B is the medium. It reads every candidate passage and decides which ones say why a line exists, under a schema that only lets it choose passage ids, then writes the answer card in plain words, where every reason must cite one of the quotes it chose. - Best Use of Render: the app and the API run on a Render web service, and Gemma runs in a private Render service with Ollama, both from one render.yaml. The AI runtime is on Render. - Best Use of Entire: "search past agent work to explain why code exists" is exactly what the séance does for agent-written code. When a line's commit carries an Entire-Checkpoint trailer, Ouija Blame reads the published checkpoint and the ghost quotes the developer's own prompt (see the agent-written séance in the gallery).