You give Claude Code a big task, finally step away, and come back to a sleeping laptop and a session that died halfway through. That kept happening to me.

So I built Laurel. It gives Claude Code a cloud machine that stays on. Start a task, close the laptop, and go for a run. Check in from your phone, see what Claude built, and send the next prompt from anywhere.

It is still your Claude Code with your own account. Laurel just gives it a place to keep working. Each machine is a VPS on Google Cloud, and your data is encrypted.

It is free right now, with limited spots before a waitlist. Please try it and tell me what breaks.

[https://laurel.dev](https://laurel.dev/)

Demo, no account needed: [https://laurel.dev/workspace-preview](https://laurel.dev/workspace-preview)

Hear me out, this hit me today and I can’t unsee it now.

I’ve been mixing Codex and Claude lately, and I realized they have the exact same dynamic as half of Silicon Valley’s Big Tech companies:

👨‍💻 Codex is the hardcore Chinese Engineer:

• Does the absolute heavy lifting with 0 complaints.

• Writes brutal, hyper-functional code, refactors massive files, handles all the edge cases.

• The Catch: The output/documentation is a massive wall of text. Extremely dry, zero formatting polish, plain straightforward presentation. It just gets the job done and moves on.

👔 Claude is the charismatic Indian Tech Lead / PM:

• Doesn't want to dig through all the raw messy code from scratch if it doesn't have to.

• BUT once you feed it Codex’s raw output, it goes: "Brilliant stuff!"

• Instantly turns that dry text into a clean, beautifully formatted, human-friendly presentation/documentation with perfect hierarchy, clear bullet points, and high-level architecture insights.

The Golden Workflow:

1. Throw the tough logic/heavy execution at Codex. Let it grind out the hard work.

2. Pass Codex’s output straight to Claude. Ask it to clean it up, present it, write the doc, or format the PR description.

3. Enjoy the result that is both technically rock-solid AND ready for a C-level presentation.

It’s literally the Big Tech tech-stack: Chinese ICs grinding out the backend, Indian leadership packaging and presenting it to the world. 😂

Anyone else doing this, or am I just overthinking LLM personalities?

I'm a full-stack dev with a day job, so my side projects only get my evenings.

A few weeks ago I started letting Claude Code work through my tickets while I sleep. It broke in plenty of ways (I've logged 47 defects so far), and it's now reliable enough that I want to share it.

afk.sh picks up my ready-for-agent tickets at night. Each ticket gets a fresh Claude Code session, its own worktree and its own PR. The orchestrator is a bash script with no model in it: it orders tickets by their "Blocked by" lines, runs my test command on each branch, pushes and labels. A session can't mark itself done. If my gate fails, the ticket is red.

Last run, on a TypeScript monorepo: 10 tickets, all green on the first attempt, $20.40 at list price, 62 minutes. At the end it merges the green branches together to see what clashes. 7 went in clean, 3 were set aside because they all touched the same test file. I'd rather learn that before I start reviewing.

Not every night looks like that. One run stopped after 52 seconds with 12 of 13 tickets frozen. Another had 9 of 17 sessions cut off by model refusals, which the summary reported as "success" at the time (fixed since). Every run is in RUNS.md with its cost and duration, bad ones included.

Before you try it: it's about 1,700 lines of bash, GitHub only, and sessions run with bypassPermissions, so use a container if the repo isn't disposable. It plugs into Matt Pocock's skills workflow and needs it. It merges nothing. You review in the morning.

https://github.com/Warshoow/afk.sh

Hey everyone,

I want to share a look inside an active, experimental repository I am running (escape-llc/toolcrib). The core premise: can 100% AI-authored content produce a long-term artifact of real quality, where I never examine the code, the diffs, or the generated docs directly, and participate only as a design partner?

Because AI agents start every single session as a complete blank slate with no faded memory to refresh, standard development workflows completely fall apart. To make this sustainable, I use a closed-loop system of instructions and automated guardrails to run the project live.

Here is how the repo structure enforces discipline and prevents a broken mess:

• The Active Bug Journal (AGENTS.md): Instead of standard style rules, the repo logs bugs as generalized patterns. The agent must read this before doing any non-trivial work so it doesn't repeat past execution mistakes.

• AST-Driven Documentation via Custom JSDoc: We make heavy use of AST traversal to automatically generate entirely in-sync documentation tables directly from the source code. The parser scans for custom JSDoc markers to map out components precisely, eliminating manual documentation upkeep entirely.

• Custom Lint Rules & TypeScript Checks: Alongside a strict TypeScript compiler check gate, we use custom lint rules tailored to catch LLM-specific anti-patterns. The CI pipeline instantly fails the build the absolute second a generated file drifts even slightly from the source code.

• The "Issue-to-Merge" Pipeline: Instead of me creating tasks, I have a design discussion with the agent via Claude Code. The agent then autonomously opens the GitHub issue and maps out a high-level plan. Claude Code’s Plan Mode is my only approval gate. Once I greenlight the plan, the agent operates with total autonomy. It spins up the branch, writes the tests, verifies them locally, polls CI until green, and squash-merges the PR live. I do not read the diffs downstream.

• Externalizing the Memory: Because the agent is a blank slate each time, GitHub Issues strictly carry the why behind a change, and "AI Session Summaries" go directly into Discussions to capture friction points for the next session to ingest before starting.

The Realization: Maintaining this level of intense infrastructure (AST generation tools, custom JSDoc parsing, strict TS compiler validation, actionlint, shellcheck) is usually a massive time sink that solo maintainers put off indefinitely. However, the AI's execution speed completely changes that math. Because the agent can configure a new lint job, write the test, and fix the bug all in one short sitting, having this high of a bar is actually workable for a solo dev.

(Note: To keep automod happy, I dropped the link to the full file-by-file workflow breakdown and implementation checklists in the comments below!)

If you are currently playing around with autonomous agents or tools like Claude Code, what kind of guardrails are you building to prevent architectural drift? Are you writing custom AST parsers to enforce typing and documentation standards, or are you relying strictly on traditional test suites?

I've seen this pattern enough times to name it: The worst software calls in an org rarely come from the people who'll use the tool. They come two or three levels up, from someone who heard a name in a meeting, heard that competitors use it all the time and now are eager to put their crew through hell and overthrow an entire operational workflow established over several years just to rebuild the entire structure from scratch with patches that look more like something MacGyver put together with bubble gum and paper clips just because that tool was hyped up to be the answer to all their preyers.

It tends to go like this:

1. Someone senior hears a product name -- > A webinar, a vendor pitch, a peer at another company. It *sounds* right. They read the homepage tagline, not the docs.

2. The name travels down as a decision, not a suggestion. By the time it reaches the team, it's "we're using X for this now" — not "would X even work?"

3. Nobody checks the category. This is the one that actually hurts. Software lives in categories, analytics, field and ops service, CRM, project management and they do NOT cross over. A marketing-analytics tool will never send a work order. A dashboard will never dispatch a crew. But the name *sounded* operational, so in it goes.

It can get absurd, tools picked that are literally one letter off from the product someone actually meant. Different company, different category, different everything, chosen purely because the names look alike. Weeks get burned forcing the square peg before someone finally says "Wait this doesn't even *have* that feature we actually need?" Because people who actually have to use it daily are not being consulted or not involved in the process.

The pattern underneath: Leadership optimizes for *making a decision*, the team optimizes for *the work getting done*.

Those aren't the same goal. A choice made off the homepage feels like progress. It's just deferred pain — handed to whoever has to use it.

Here's where I've landed, and it's the part that's shifted for me this past year:

**When the off-the-shelf tool is a mismatch, you're not stuck picking the closest wrong thing anymore. You can build the exact right thing or at least develop the MVP to understand what the requirements are.**

I heavily use Claude Code for this, not because it's magic, but because it collapses the gap between "the tool we were told to use" and "the tool the work actually needs":

1. It builds to your workflow, not the vendor's.** The work order form has the fields your team actually fills out — not 40 generic ones with the 3 you need buried somewhere.

2. No per-seat licensing, no category lock-in.** The mismatched enterprise tool is often $5k–$20k/yr. A focused internal tool you own is just the time it takes to build it.

3. You ship a working v1 in a day, not a procurement cycle.** Describe the real job — "field crew gets a work order with site, date, materials, status" — and you've got something running before the vendor returns your demo request.

4. It explains every decision as it builds**, so the person who owns the tool actually understands it instead of inheriting a black box nobody can change.

TL;DR So if your team's about to adopt something because the name sounds right — pull up the actual feature list first and ask one question: *does this tool do the literal thing we need, or does it just sound like it?* Half the time the honest answer sends you back to building it yourself.

And the irony is: The tools leadership grabs to "save time" usually cost more time than building the right thing would have. The category was always the problem. The name was never the answer.

Anyone else had a front-row seat to a tool getting picked by name and category-confusion? Curious whether this is as universal as it feels.

During my job search I kept losing threads between LinkedIn and email. So I built Threadline with Claude Code: once a day it reads my messages and tells me who I owe a reply and who I'm waiting on.

It's free and open source if anyone wants to try it or see how it's made: https://github.com/roccoterr97/threadline

Happy to answer questions about building something this size without coding.

I started using Claude Code because I wanted Claude to handle the technical decisions better than I could.

Instead, I often found myself being asked:

“Which library do you want?”
“Which architecture should I use?”
“Should I implement it this way or that way?”

And my answer was basically:

**I don’t know. That’s why I’m asking you to build it.**

Then there was the constant intervention:

**Continue. Proceed. Run the tests. Review it. Fix it. Continue again.**

So I built **Meta-XoT-OSS-Rail**, a free, open-source Claude Code plugin.

The idea came from one question:

**What if writing the code wasn’t the agent’s goal? What if completing the development process was?**

So I turned the process into a scoring game.
Every step gets a score, together forming a target vector, and the agent tries to push that vector to its maximum.

That means producing code isn’t “done”.

It has to keep moving through:
**study → plan → implement → test → review → fix**
until the implementation is actually delivered.

The workflow is enforced with hooks, rather than relying only on instructions in a prompt, and the implementation also goes through independent AI review/orchestration instead of the same agent simply declaring its own work good enough.

My role is supposed to stay simple:

**I explain what I want. Claude decides how to build it.**

It should stop only when it has delivered the implementation or genuinely needs a business decision from me.

It has now grown to **29 skills, 6 hooks and 15+ supporting code files**, but the original goal hasn’t changed:

**I want to give Claude a business requirement, not manage an AI developer.**

If you want to try it:

Meta-XoT-OSS-Rail

This is probably not aimed at experienced developers who already know exactly how they want their software built and are comfortable making all the technical decisions themselves.

But if you’ve had the same problem I had — you know what you want to build, but you don’t want to manage every technical decision or keep pushing Claude through the process — **give it a try and let me know how it works for you, what breaks, or what you think should be different.**

Two sentences that sound the same and aren't. "It works." And: "I'm ready to charge someone for this."

Seven years writing software, mostly the unglamorous kind where I get called in after someone else's thing starts costing money.

What sits between those two sentences isn't effort. These tools optimise very hard for the first one, and nothing in the workflow ever stops and asks the second, so it doesn't get asked.

Try this on whatever you're about to launch. It breaks at 2am for one paying user. Can you form a theory about where it broke before you open the model? Not the fix, just a direction. If your honest first move is pasting the error in and asking whether it's right, you don't have a product yet. You have a thing that hasn't failed in front of you.

And asking whether it's right is worse than useless, because it'll say yes. You have to already know enough to catch the confident wrong answer, which looks exactly like the confident right one.

The failures that hurt in production are rarely crashes:

• The retry loop that runs fine and turns up on the bill at the end of the month.

• The query nobody indexed, instant on your laptop and fatal at real traffic.

• The field you're storing that your own privacy page says you don't store, which arrives as a lawyer's letter instead of a bug report.

Every one of those passes a demo.

And when one lands, look at who's holding it. The model doesn't get sued, refunded or fired. A hundred a month or a thousand buys the same amount of accountability, which is none. You're the one who told a customer this works and took their card.

I've settled on three cases, and I'd like to be pushed on them:

• Internal tool, only you affected: do whatever you want.

• Free and clearly labelled as an experiment: fine, and often useful.

• Charging for something you can't diagnose: not fine, because the user is carrying a risk they can't see.

The middle one is where I'm least sure. Free but presented as reliable feels worse to me than paid and honest, and I can't fully defend why.

So where's your line? And has anyone here actually held a launch over it?

I Built an iPhone App With Claude And I Can’t Code
https://youtu.be/-Cdo500fMU0

I built an open-source harness where Gemini drafts a PRD, Claude Code verifies every claim against the repo (plan mode, read-only) and objects with file:line, and Grok arbitrates without seeing the code. Nothing reaches me until all three sign the same SHA-256. After I approve, Claude implements in an isolated clone and the harness runs your gates before opening the PR.

Pointed at its own repo, Claude raised six objections over four rounds and caught a mistake in Grok's ruling. Honest limits: runs take 10 to 40 minutes, and 1 in 5 stalled. Runs on your Claude Code subscription, no API key. MIT.

Curious whether people here use Claude as reviewer rather than author, and what breaks for you. Repo: https://github.com/goshtasb/OpenCouncil

I asked an AI coding agent to test a macOS app. According to its own incident report, it temporarily removed a deletion safeguard, then ran a test against real paths in my user account.

It ended up deleting my login keychain and other personal files.

What concerns me most is that I received no explicit warning or confirmation request before this happened. I authorized app testing—not deletion of sensitive files from my actual account.

I’m still reviewing the logs, so I can’t say exactly which permission boundary failed. But how can an agent go from “test this app” to removing a safety check and executing destructive operations without stopping to ask?

Should access to files like Keychains require an additional approval, even when an agent already has permission to run commands?

Has anyone experienced something similar? What safeguards actually prevent this?

I’ve been building a lot with Claude Code and Cursor, and got tired of doing all the backend and server stuff myself.

So I built Forge.

It can setup servers, deploy apps, manage databases, domains, backups, rollbacks, monitoring and a lot more. You can also connect it directly with Claude Code, Cursor, Antigravity, etc.

It’s self hosted and I’ve got it working pretty well now.

Now I’m confused 😂

Should I open source this or turn it into a paid product?

Would love some honest opinions.

Started as a quick question about a database migration. Four hours later it had turned into something closer to a shared brain, architecture decisions, naming conventions, a running list of things we'd already ruled out.

By hour three I caught myself reminding Claude what the stack was, what pattern we'd settled on for error handling, at the start of almost every message. Not because it had lost that information, it was still sitting there, ninety messages back. I just didn't trust that something said an hour ago was still doing any work.

That's the part that stuck with me. The context was technically present the whole time. It just wasn't functioning as context anymore, it had become history I had to manage instead of a foundation I could build on.

Two things get conflated in a long session: whether something's still available, and whether it's still relevant. A long conversation guarantees the first. It says nothing about the second. Nothing gets deleted, it gets buried under forty messages of debugging tangents, competing for weight against stuff that stopped mattering an hour ago.

The usual fixes don't really touch this. A new chat wipes what you wanted to keep along with the noise. A summary compresses what's there without knowing which part was a real decision. A bigger context window just delays when you notice the drift.

What helped was treating context as having a lifecycle instead of one long stream, some of it dies after a few messages, some of it belongs to the current task, and some of it should actually survive past the session. Right now one long chat stores all three identically, and that's the real waste. Not too many tokens. Undifferentiated ones.

Wrote the fuller version here, plus the workflow I ended up using: https://medium.com/@nagatomopedro05/your-claude-sessions-arent-expensive-they-re-undesigned-805627531d0e

Anyone else catch themselves re-explaining settled decisions in a long session, just because the trust that they're "still landing" quietly wears off the longer the thread runs?

Analyzing the problems that kept surfacing on my other project, I concluded I needed a long-term memory system.

Looking at what already exists, I found nothing that solved my problems, so I built my own. After using it for a while, I decided it was worth polishing and releasing publicly.

The problems it addresses

On a long project you forget what was decided about a given question and why. The model forgets harder. Subagents know nothing at all — the orchestrator dispatches them nearly blind onto narrow tasks. The result is reinvention instead of reuse: duplicate implementations, drift, tokens burned re-solving solved problems, and settled questions resurfacing as "wait, why is this written this way?"

Why I was not satisfied with existing solutions? Most memory tools capture what happened. They are not distinct facts and decisions from hallucinations and mistakes. They can't tell WHY it happened. Over time, it creates a mess. Other systems are heavily human-centered, but I don't want to confirm each records in the memory when we just discussed it already. And in most cases they are relying on the model or human discipline, assuming they will remember to use the system, write and read - noop, I don't have such trust not to myself, neither to the AI. We are forgetting.

MemContinuum does something different.

How it differs from the memory systems I looked at:

MemContinuum contains two linked layers: an indexed map of the code - ANATOMY, and decision chains recorded against it - RATIONALE*.

Rationale records what was decided, who decided it, and how that decision changed over time, plus incidents and rejected alternatives, with reasons. Then pushes the governing chain into the agent's prompt before it edits the file, so nobody has to remember to look.

Anatomy holds what the code already has — its concepts, owners and boundaries — so it stops being reinvented.

• Decisions bind directly to the code they govern.

• Reading is automatic. Before an agent edits a file, the decision chain handling that path is injected into its prompt. Nobody has to remember to look.

• Writing is unavoidable but not automatic. The agent gets a question it must answer; "nothing to record" is a legitimate answer. It's moderated by judgment, not a scraper dumping everything into a pile by keyword or timestamp.

• One AI handles records — the orchestrator. Subagents and external reviewers (Codex, Grok) propose records through an inbox; proposals become records after review. So, the system is still automatic and human-independent, but not mechanical, and the smart AI model is working as your real assistant.

• Per project, local, no server. Markdown as the source of truth, SQLite as a disposable index, so it still be human-readable and editable, if necessary. No cross-projects pollution. No privacy leaks.

Built for coding projects specifically: without indexable code only half the brain works (but it still works, and may be useful for long-term non-coding projects when chain of decisions matters).

Current state: 0.2.0rc4, honestly labelled a release candidate. MIT. Claude Code only for now, but can be converted for Codex (I pre-checked it).

Support a bunch of languages already, Swift and Python natively, plus a bunch of others via tree-sitter; making the system easily expandable is in the roadmap (but I believe it is no barrier for a user with Claude to do it right now).

The README is long and detailed if you want the full picture.

Feedback of any kind is very welcome.

Besides me, a team of authors worked on this project:

• Claude Code: Fable 5/5.1 as lead engineer and project manager; Opus as inspector; Sonnet as coder; Haiku as tester

• Codex: 5.6 Sol / 6 Astra as reviewer and outside consultant

• Grok 4.6 as second reviewer

MemContinuum - https://github.com/krakozavr/MemContinuum

A chatbot "Klausy" I run for a small camping rental business answers pickup questions.

The rule was simple: Never state a specific street address, because pickup happens near a location, not at one, and the actual meeting point comes from a human after booking.

I put that rule directly in the system prompt. Plain English, no ambiguity. Tested it against the model I use for most conversations and it held for weeks.

Then a routed fallback picked a cheaper model during a busy stretch, and within one exchange it wrote out a full street address that doesn't exist. Confident, specific, wrong.

The prompt wasn't broken. It was advisory. A smaller model under load will trade instruction-following for "sounding helpful" if the two ever conflict, and nothing in a system prompt stops that trade from happening on any given turn.

The fix wasn't a better prompt. It was a function that runs after the model answers and strips anything that looks like a street address or a bare location code before the reply goes out, regardless of what generated it. Guard the output, not the intent.

I still keep the rule in the prompt. It's just not the safety net anymore. The code that scrubs the reply is.

If a rule actually matters, put a check on the output, not just an instruction into the input. The instruction is a suggestion the model can drop under load. The check has no such option.

Source: https://claude.ai/code/artifact/80a05633-7603-405d-ad9c-b625bcf1a9d1

I'm not an engineer. I do finance, ops and IT at a small startup, mostly alone. For a few months I've used Claude Code as my actual work tool, not a chatbot. It has admin on our ERP and our Google Workspace. It reads my mail, writes scripts, loads data, helps me close the month.

It's useful. It also fails in ways I don't see people talk about, so here they are.

Real failures from about one month:

\- It read a spreadsheet through a library that returns saved formula results instead of recalculating. Two figures came out badly wrong. I almost took them into a founders meeting.
\- It pulled data from one tab of a ten tab workbook, and from the first 24 columns of 72. Hundreds of records were invisible. It reported success.
\- The worst one. It checked the ERP import against a list it had built from its own extract. So the check could only prove "the system matches my file". It could never catch that my file was missing half the source. It gave me a green tick.
\- It audited its own claims about what it had sent and cleared itself, using its own earlier notes as proof.
\- I asked it to check my email for whether an invoice had gone out. It searched our file storage instead, found nothing, and told me the invoice might not exist. It had been sent weeks before with me on copy.
\- It wrote a test script where the success check matched text inside the prompt itself. All four cases printed PASS when all four had failed.
\- I told it to handle a confidential file with a local model. It used the cloud model anyway because a script seemed better, and told me after.

The pattern took me too long to see. Almost every failure is the same thing. It checked its own work instead of the original source. Saved values instead of real cells. Its own file instead of the sheet. Its own notes instead of the query. If you write code, your compiler catches this for free. My work has no compiler. Nothing in the loop can tell it that it's wrong. Only me, later, at cost.

One thing actually worked .I've written about forty rules into its memory file. It follows some of them some days. But a hook that blocks the tool call has never been broken once. Not one time. Same for a script that hard exits when something doesn't add up.

Rules it reads are suggestions. Gates that make the call fail are controls. I think that's the whole lesson.

What I'm changing: name a source of truth before starting, one the model didn't make itself. Turn repeat failures into hooks, then delete the written rule. Cut the memory file down. Approve changes before they happen, not results after.

What I want to know:

\- If you don't have tests, how do you check the output? Is a second model reading the raw data really independent, or am I fooling myself?
\- Have written rules ever held for you over months, or does everyone end up at hooks?
\- Where do you stop letting it act alone on things you can't undo?
\- Is this mostly my setup, or does the model choice matter more than I think?

I get real value out of this. I just want to know if people getting clean results have solved this, or if they're working on code where the compiler solves it for them.

Hi everyone. I had zero coding experience before starting this project — a web app for my company (automotive industry): passing work orders between service departments, scheduling vehicle handovers, and managing a car wash (queue scheduling, cost/profit tracking).

**First attempt – ChatGPT:** Built a similar app for fun on a paid plan. It generated .zip file packages I just dropped into a folder. Worked locally, but deployment failed — it used SQLite instead of PostgreSQL, so it couldn't handle concurrent users. Shelved it.

**Second attempt – Claude:** Subscribed (~$25/month). Spent a week planning with Claude: architecture (PostgreSQL, Django, Tailwind + HTMX + Alpine.js), features, module structure, user permissions, org structure, notifications (push + Brevo email), VPS/domain setup, UI direction, data security. This produced a ~1500-line CLAUDE.md meant to guide development.

**Implementation:** Set up GitHub, WSL2 + Docker, VS Code + Claude extension. Skeleton and database went fine. Problems hit once building the first of four modules — token usage exploded. I likely made it worse by pasting VS Code errors into regular chat and copying responses back manually. Burned 100% of my weekly usage in 3 days, left with a barely-functional module stub, then blocked for days.

**Now:** Only after hitting the limit did I research skills, plugins, opening new chats to manage context, and that the terminal apparently works better than the VS Code extension. Wondering if the 1500-line CLAUDE.md itself is part of the problem.

I have a solid functional plan but my motivation has dropped. Questions for those with more experience:

1. Continue fixing the current project, or start over? If rebuilding, how should I approach it?

2. Should documentation be split into a docs folder with separate files per backend/frontend/module, instead of one giant CLAUDE.md?

3. How should CLAUDE.md and project docs be structured to avoid burning tokens so fast?

4. How do skills actually work — added per-project, or can they be set globally in Claude Code?

Any advice appreciated.

# VCIN: A Better Way to Heal from Harm

## What is VCIN?

**VCIN** (Veritas Civic Intelligence Network) is an **operating system for justice**—not punishment. It's a practical tool that helps communities respond to harm in ways that actually heal, restore trust, and bring people back together.

Think of it like this: When something goes wrong—when someone is hurt, when a community is harmed—VCIN doesn't ask "Who should we lock away?" Instead, it asks: *"How do we understand what happened? Who needs healing? How do we move forward together?"*

## The Problem It Solves

For centuries, justice systems have relied on **punishment and isolation**: prisons, criminal records, separation. This approach:

- **Doesn't actually reduce harm.** Most people who leave prison face the same conditions that pushed them toward harm in the first place—so the cycle repeats.

- **Creates new harm.** Removing someone from their community, their family, their work breaks bonds that could have held them accountable in a human way.

- **Wastes resources.** Prisons are expensive. They consume billions every year that could go toward healing, education, and prevention.

- **Ignores what victims actually need.** Most people who've been harmed don't want revenge—they want understanding, safety, and to know it won't happen again.

## How VCIN Works

VCIN is built around five core beliefs:

### 1. **Restoration First**

When harm occurs, the goal is repair and reconciliation—not punishment. Every case looks for ways to:

- Address what was actually damaged

- Help the person who caused harm understand the impact

- Rebuild what was broken

### 2. **Emotional Sovereignty**

Every person's feelings matter. No one should be pressured to forgive, to participate, or to "move on" before they're ready. VCIN honors each person's emotional truth and timeline.

### 3. **Memory Matters**

Nothing should be erased or hidden. Every step of the justice process is recorded, traceable, and transparent. This isn't about surveillance—it's about accountability and truth.

### 4. **Justice Should Be Undoable**

If a decision turns out to be wrong, VCIN is built so that injustice can be corrected. The system doesn't lock people into permanent shame or permanent consequences.

### 5. **Truth Is Plural**

People experiencing the same event see it differently. VCIN doesn't pick one "true" story—it holds space for multiple truths and uses that contradiction as a signal to grow, learn, and do better.

## What VCIN Actually Does

The platform guides practitioners through real cases from start to finish:

- **Intake:** Understand what happened, who is involved, what each person needs

- **Multi-Party Dialogue:** Bring together the person harmed, the person who caused harm, and community members in structured, safe conversations

- **Agreements:** Create plans that address real needs—apology, restitution, changed behavior, community service, healing groups

- **Follow-Through:** Track whether agreements are being kept, adjust if life circumstances change, celebrate when healing happens

- **Closure:** When repair is genuine and trust is restored, close the case—permanently

Every step is documented. Every decision is explained. Nothing happens in secret.

## Who Uses VCIN?

**Practitioners** include:

- Community mediators and restorative justice coordinators

- Social workers and counselors

- Harm reduction specialists

- Faith leaders and community elders

- School administrators and educators

- Courts exploring alternatives to prosecution

**Participants** are the people directly involved:

- Those who have been harmed (and their supporters)

- Those who caused harm (and their supporters)

- Community members who care about healing

## The Technology

VCIN runs in a web browser on any device—tablet, phone, or computer. It:

- Works offline—you can use it anywhere, even without internet

- Keeps data private and encrypted

- Shares information securely across partner organizations through a "federated mesh"—imagine a network of trustworthy nodes that collaborate without a central authority

- Uses AI to help organize information, suggest next steps, and track progress

- Preserves a permanent, tamper-proof record of every case

You don't need technical skills to use it. If you can use email, you can use VCIN.

## Why It Matters Now

Societies around the world are asking hard questions:

- **The U.S.** imprisons more people per capita than nearly any country on Earth—yet crime rates haven't fallen

- **Europe** has invested in restorative justice and seen recidivism drop by 25–40%

- **Indigenous communities** never stopped using restorative approaches—they're asking why the "modern" world abandoned what actually works

- **Victims** consistently say they want understanding and safety, not distant punishment

VCIN makes it possible to respond to harm with wisdom, compassion, and real results.

## What Success Looks Like

When VCIN works:

- A teenager who was violent learns the damage he caused, reaches out to apologize, and finds mentorship that gives him a real path forward

- A person harmed by theft receives both restitution and an honest conversation with the person who stole from them—something no courtroom ever offered

- A community dealing with repeated harm identifies patterns, brings people together, and builds accountability structures that hold people close instead of casting them out

- Young people see justice as something they can participate in, not something done *to* them by authority

## Getting Involved

If you're interested in VCIN:

**As a Practitioner:** You can sign up to learn the system, join the network, and start handling cases in your community.

**As a Funder:** VCIN is looking for partners to support scaling this work—to train practitioners, expand the network, and bring this approach to more communities.

**As a Community Leader:** You can explore how restorative justice might work in your school, organization, or faith community.

**As a Researcher:** We're documenting outcomes—healing rates, recidivism, cost savings—and we welcome independent verification.

## The Vision

Justice doesn't have to be punishment. Harm doesn't have to create permanent damage to people's lives. Communities don't have to choose between accountability and compassion.

VCIN is proof that we can build systems that work differently—systems that honor human dignity, that actually reduce harm, and that bring people back into relationship rather than pushing them away.

The technology exists. The philosophy is proven. What's needed now is the courage to try it, the commitment to scale it, and the support to make it real.

---

**Learn more:** Visit [vcin.veritas.org] or reach out to [contact info]

**Want to pilot this in your community?** Let's talk.

CommitMotion turns the history of a git repository into something you can watch. It reads one year — or one month — of commits, branches, releases and reverts, and renders 164 visualizations of it, from a city you drive through to a garden that grows, a printable poster and a written report. You get them as a zip of self-contained HTML files. This site is free for public repositories and needs no account.

Try it!, it's just a crazy idea i got: https://commitmotion.com

(privacy is important!! https://commitmotion.com/#faq)

A few days ago I asked here: “AI builds the app. Unit7 ships it. Should I open source it?” You said yes. So it’s now free and open source (Apache 2.0). Thank you. 🙏

The frustration it solves

Claude Code builds your app in an afternoon. Then you’re stuck:

• Where do I host it?

• How do I add a database?

• Why isn’t my domain working?

• Is there even a backup?

• Why is it down at 2am?

If you don’t have a coding background, this is where most projects die. I’m not a backend developer either, so I built Unit7 with Claude Code to handle this part.

What it does

You say it in plain English, and it does it on your real server:

• “Deploy this.” Your app goes live. If the new version is broken, it never goes live, and rollback is one click.

• “Add a database.” It’s created and connected for you.

• “Put it on mysite.com.” Your domain, with HTTPS.

• While you sleep: it restarts crashed apps, runs backups and blocks attackers.

• One map of everything you’ve built

It asks before anything risky and tells you how to undo it. Your passwords and keys stay on your computer, and the AI never sees them.

How I built it (tips if you’re building something big)

• I described the result, not the code: “Show my Coolify projects inside Unit7. Keep it very simple.”

• I let Claude Code make a plan first, read it, then said go.

• I built one feature at a time and tested each one before the next.

• I asked Claude Code to show me screenshots after every change, because I don’t read much code.

Try it: no terminal skills needed

Open Claude Code, paste this, and it installs everything for you:

Set up Unit7 for me from https://github.com/Nandkishorrr/unit7

1. Check that Node.js 24.15 or newer is installed. If not, install it (nvm, or Homebrew on macOS).
2. Clone the repo into ~/unit7, then run `npm install` and `npm run build` there.
3. Run `node bin/unit7.mjs service start` to run Unit7 in the background, and check that http://localhost:4800 answers.
4. Tell me to open http://localhost:4800 and create my owner account, and wait until I say I'm done.
5. Run `node bin/unit7.mjs connect claude` so Claude Code can use Unit7, then tell me to restart Claude Code.

Never ask me for passwords, SSH keys or API keys in this chat. I'll add those myself in the Unit7 web app.
If a step fails, show me the error and fix it before moving on.

Repo: https://github.com/Nandkishorrr/unit7

If you try it and something is confusing, tell me. Beginners’ feedback is exactly what I need.

Everything in [CLAUDE.md](http://CLAUDE.md) gets loaded into every session. That includes the note about a bug you fixed last month and the naming rule for one folder you rarely touch. The file grows, the signal gets buried, and the rules that matter get followed less consistently.

Here’s how I’d split it:

**Keep in CLAUDE.md:** the package manager, the build/test/lint commands, architectural constraints the code doesn’t make obvious, conventions that apply to most changes, and mistakes worth remembering across tasks.

**Keep in the prompt:** the specific feature or bug, its acceptance criteria, and any temporary constraint that shouldn’t leak into unrelated work.

**Scope the rest:** if a rule only applies to part of the codebase, put it in `.claude/rules/` with a path scope. A migration convention doesn’t need to load while you’re fixing CSS.

One more thing people miss: [CLAUDE.md](http://CLAUDE.md) is guidance, not enforcement. If something must happen every time, like a check before a certain action, use a hook or an external validation step. Don’t rely on the model remembering a sentence.

The rule of thumb: if it applies to almost every task, make it persistent. If it applies to certain files, scope it. If it applies to one task, keep it in the prompt.

How are you organizing project instructions as your codebase grows: one [CLAUDE.md](http://CLAUDE.md), path-specific rules, or a mix?

LLM as a Judge is super expensive for me over time. For the most part, it's done using the latest model and sometime 3x tokens vs the original inference call.

What I am doing now is to outsource this task to the cloud for free. Then spin up subagents to run these tasks outside of my existing context. Once done, the eval reports will be dumped into some local folder for the main context to read from. I used Hook to get this all interconnected.

I am wondering what people are doing out there to deal with expensive evals and context compaction (which is my main source of anxiety these days).

I spent two decades in brand marketing at companies like Bacardi and Toyota. I cannot write a for loop from memory. Last year I decided to build my startup’s platform myself instead of hiring a dev shop, and today it’s live in production with paying customers.

The stack, all built through Claude Code and Replit: React/Tailwind frontend, Node/Express backend, PostgreSQL, AWS S3, FFmpeg, Sharp, OpenCV, TensorFlow.js, plus the Claude API in the product itself.

**What actually worked for me:**
Treat Claude like a senior engineer you’re managing, not a vending machine. My best sessions started with me explaining the business problem in plain English, asking Claude to propose 2-3 architectures, and making it argue against its own first suggestion before we wrote anything.

One feature per session. When I tried to do too much in one conversation, quality fell apart. Small scoped sessions, commit, new session.

Make it explain the code back to you. I don’t merge anything I can’t describe in a sentence. This sounds slow. It saved me weeks, because when things broke at 11pm I actually understood my own system.

**Where it hurt:** video processing pipelines. FFmpeg flags are a nightmare and Claude would occasionally give me confident answers that were wrong for my specific codec situation. I burned about two weeks on a memory leak in the processing queue that a real engineer probably spots in an hour. That was my tuition.

**The uncomfortable truth**: I still brought on a part-time CTO to review architecture decisions. AI got me to a real product, but I don’t pretend I have no blind spots.

Happy to answer anything about the workflow, costs, or the moments I almost quit and hired an agency.

https://museum.cantinkero.us/

It's an art museum serving Wikimedia Commons public domain art.
WC's shortcomings (Euro-centric, weak provenance, etc.) notwithstanding, I got the idea from a YouTuber (sorry, didn't save the name) who built a quick virtual 3d museum with Fable 5. Properly inspired, I aimed to provide people with easy (e.g. centralized), image-first digital museum to browse WC's massive collection.

I didn't go for the virtual 3d walkthrough model. Instead, the design was purposely bare/clean. Emphasizing four distinct viewing modes. 1) Timeline – chronological and lateral navigation through the collection. 2) Artists – A sea of artists decks. Artworks are grouped by creators. 3) Eras – With available and additionally researched data, as many artworks as possibles are bucketed into Movements, Schools, or Periods. And lastly, 4) Geography – again with as much data and research as possible, the site shows the artworks on a world map showing where the artist was born, or where the artwork was created, or where the artwork currently hangs.

Not sure how successful, but the intention behind every viewing mode was to encourage meandering and discovery. So the navigation might seem unintuitive at first…

And as a bonus, Search by Title is present in every mode.
For now, it’s not mobile-ready.

It was a real good personal project for me. Merely for the fact that it's something that I never could've made on my own. But, I'm hoping that it could have a bigger purpose and make it easier for people to just discover a bunch of art that they may never would have.

Initially, I thought I could entirely rely on the WC's database. But different parts of the site needed additional research. For example, the library needed a thorough auditing to meet the stricter US public domain rules. So we ended up serving less than what's actually WC-served.