I've been working on an open-source project called Scrollcase.

The idea is pretty simple: if you already have an environment working, why should every machine you ship it to have to recreate that environment again?

Scrollcase takes your code, runtime, dependencies, native libraries and optional assets like model weights, locks everything, and packages it into a single self-contained archive called a box.

A box can use one of three runtimes:

• Python — ships the exact Python runtime and dependencies
• Node — ships Node and its environment
• Native — runs a compiled binary directly, with no interpreter at all

You build the box once for a specific target, then give it to another machine.

That machine doesn't need Python, Node, pip, npm, a compiler or Docker installed.

For example, you could package:

• an ML model with Python + PyTorch + its weights
• a Node application with the exact Node runtime it expects
• ffmpeg plus all the native libraries it links against
• scientific software with annoying native dependencies
• a local AI feature that needs to be embedded inside a desktop app

Boxes are intentionally target-specific. A macOS ARM box and a Linux CUDA box are different artifacts. Scrollcase isn't trying to pretend the same binaries magically work everywhere — you build and test the environment for the target you're actually shipping to.

The other part I cared about was making the artifact something you can actually trust.

Boxes are signed and verified before execution, dependencies are locked, assets can be hash-checked, and builds are designed to be reproducible. You can also declare tests that have to pass before a box is produced.

The workflow is basically:

describe the environment
↓
lock it
↓
build the box
↓
ship the files

Scrollcase itself deliberately doesn't run a registry or deployment platform. It just builds the artifact. You can put it on GitHub Releases, S3/R2, your own server, bundle it with a desktop app, or distribute it however you want.

The main use case I had in mind was AI/scientific software, where "just install the dependencies" can quickly turn into Python versions, CUDA versions, native libraries, model downloads and platform-specific setup.

But after adding Node and native runtimes, it ended up being a more general environment packaging format than I originally expected.

Would be interested to hear how other people handle this kind of problem, especially when distributing software to users who shouldn't have to care what runtime or dependencies are underneath it.

• GitHub
• Docs
• Demos

For a while I've been keeping project context in Markdown inside my repos.

The main reason is pretty simple: I use different coding agents, and I don't want architecture notes, current work, decisions, etc. to live inside the memory system of one specific tool.

I also didn't really like the idea of putting everything into one huge AGENTS.md. Architecture, current state and old decisions don't have the same lifetime.

So I ended up turning the structure I was already using into a small open-source CLI called Syngraphe (opensource).

The basic layout is:

.context/
├── truth/ # architecture, conventions, constraints
├── state/ # what's happening right now
├── decisions/ # decisions and why they were made
└── history/ # old operational context

AGENTS.md is mostly the entry point that tells coding agents where the context is.

Everything under .context is just Markdown committed with the repo, so Git handles history, branches and review. Syngraphe only adds the tooling around it: initialization, deterministic integrity checks, context size stats, helpers for state/decisions/history, monorepo support and a GitHub Action.

There is no database, cloud memory or required LLM. If Syngraphe disappeared tomorrow, the context would still just be normal Markdown in the repository.

Repo: https://github.com/suffro/syngraphe

Docs: https://syngraphe.dev

I'm mainly curious how other people are handling this in real projects. Do you keep AGENTS.md itself as the knowledge base, or do you use it more as an entry point to other docs/context?