Compounding Across Sessions, Hosts, and Teams

For gstack, the next source of leverage is not another one-off command. It is the ability to preserve a useful decision, turn a successful browser flow into a tested procedure, and distribute the same method across different agents without losing scope or provenance. This chapter separates those memory and distribution layers so the reader can judge what is genuinely cumulative and what still requires validation.

The distinction matters because “memory” can mean several incompatible things. A short note about a project convention is not the same as a release checkpoint. A semantic search system is not the same as a tested browser procedure. A generated skill for Codex is not the same artifact as the template that created it. gstack’s design becomes clearer when each layer has a scope, an owner, and a reason it is allowed to influence future work.

Five kinds of durable context

An operational learning records something that would save time next time: a recurring command failure, a project quirk, or a mistaken approach. The project can log these learnings after a skill session and expose them through /learn. They are useful suggestions, not authoritative product decisions. A learning can become stale when the code changes, so the system supports search, review, pruning, and source attribution.

A durable decision is stronger. It records a choice and its rationale, such as selecting one data boundary over another or deciding to defer a scope expansion. gstack’s decision store is intended to work even when optional semantic memory is turned off. That makes it a reliable file-based record of why a choice was made, rather than a best-effort retrieval of similar language.

A context checkpoint is about work in progress. /context-save and /context-restore preserve the current state, remaining work, and decisions so a session can resume after a crash or a workspace handoff. Continuous checkpoint mode can commit local WIP context with a structured body and later filter those commits during shipping. The checkpoint is not a new opinion about the architecture. It is a way to preserve the state of an unfinished operation.

Semantic memory, through optional GBrain integration, adds another layer. It can search project knowledge and code, but the repository gives each remote repository a trust tier: read-write, read-only, or deny. A read-only client can use shared knowledge without writing its own assumptions back into the corpus. The distinction protects the memory source from becoming an unbounded mixture of every project that happened to query it.

A browser procedure is different again. A browser-skill does not merely remember that a site has a certain button. It records a repeatable operation in code, with metadata, a vendored client, fixtures, and parser tests. That procedure can be run with a scoped token and can be resolved at the project, global, or bundled tier. The procedure has more authority than a note because it can act, so it needs stronger provenance and validation.

Imagine returning to a payment decision several weeks later. An operational learning might say that this project’s tests use a particular factory helper. A durable decision might say that payment authorization remains server-side because the team rejected client-held credentials.