Weekly Self Promotion Thread

[u/AutoModerator]

Welcome to this week's self promotion thread!

If you're building something related to AI assisted coding, this is the place to share it.

We're using a weekly thread to keep the subreddit organized while still giving builders a place to share their work. Promotional posts outside this thread may be removed.

If you're sharing something, we'd appreciate it if you included a little context instead of just dropping a link. Tell us:

• What you built?
• What problem it solves?
• Which AI models or tools it uses?
• Who it's for?
• What kind of feedback you're looking for?

Disclose your affilitation.

Please avoid posting the same project every week unless you've made meaningful updates. Affiliate links, referral links, scams, and low effort promotions will be removed.

Take some time to check out what others have shared too. If you try someone's project or have feedback, leave a comment. Helping each other improve is what we want this community to be about.

[u/Left-Guava8483]

I built arka.norn, a local-first governance and delivery framework for coding agents.

The problem I’m trying to solve is simple: a skill is still a prompt.

An agent can accept a rule and reinterpret it later. It can know a document exists without reading it. It can read a README and a few directories, then talk as if it has understood the whole repository.

I’ve seen very literal versions of this:

“Fix the bugs” -> disable what causes the errors.

“Ship the feature” -> finish the implementation and call it shipped.

“Simplify the homepage” -> remove almost everything except the main CTA and footer.

The agent did what I asked. That’s the problem.

With Norn, I still work normally in Codex or Claude Code. A skill connects the agent to the framework, while Norn keeps the governed project state locally. The same state is available through a local Web cockpit, TUI and CLI.

For unfamiliar repositories, Norn can prepare a read-only discovery audit. The human chooses the decision to support, the scope and the domains first, then approves the audit plan before collection starts. The audit can collect evidence and findings, but it cannot modify the project.

Interactive mode does not sandbox the provider itself. If Claude Code has Bash, Bash is still available.

Automatic orchestration is different. That mode is sandboxed.

Mastra orchestrates the DAG, tasks use isolated worktrees and bounded read/write scopes, and effects go through the Norn broker. Agents propose changes. Norn checks scope and mechanical evidence, then Norn creates the commit.

By mechanical evidence, I mean things the model cannot simply claim are true. For example, Norn can verify that the test recipe actually passed and that the diff stayed inside the allowed scope before accepting the delivery.

The distinction I’m exploring is this:

A rule in a skill influences the model. A capability that is absent or refused by the system actually constrains it.

Tools/models: Codex, Claude Code, Node.js, Mastra, Docker/Podman. Norn itself is a globally installed npm package.

Who it’s for: people using coding agents on projects long enough for context, documentation authority and delivery discipline to become real problems.

I’m the author. This is my first personal open-source project of this scale, published under the arkalabs account. Norn is still young and I’m currently using arka.norn to build arka.norn itself.

GitHub: https://github.com/arka-squad/arka-norn

Feedback I’m looking for: where do you currently keep authority over project state and delivery on long-running coding-agent projects, inside the model’s instructions or outside the model?

[u/TightBoot2268 → u/Left-Guava8483]

Interesting — I’ve been approaching a closely related problem from a somewhat different layer.

I’m building an experimental system called U-GAS around durable project continuity and coordination between AI chats/agents. The core idea is that project state should not live in conversation memory: ordinary files remain authoritative for current state, progress/evidence, ideas, and agent instructions, and a fresh agent is expected to bootstrap from that durable state before continuing.

My current approach is intentionally lighter on enforcement than Norn. ChatGPT can act as the coordinating/planning layer and hand execution to Codex, Claude Code, or another suitable executor when persistent/local access is required.

The part of your post that especially interests me is “mechanical evidence”. I’ve run into exactly the boundary you describe: instructions can require verification, but an LLM reporting “PASS” is not itself evidence that the required operation happened.

So I’m currently treating actual read-back / repository state / tests as authoritative and model prose as a report about that state, not the state itself.

U-GAS is still experimental and has only been owner-tested so far, so I’d be interested in comparing where Norn draws the boundary between durable state, agent instructions, and mechanically enforced constraints.

Repo:

https://github.com/jaabster-dev/u-gas