LOCAL-FIRST ENGINEERING MEMORY

Above the repo.Beyond the session.

Lattice is a local-first engineering memory and workflow layer for AI-assisted development. Specs, tasks, decisions and experience are captured once in ~/.lattice and reused across projects, sessions and agents.

Try the live demo Get started

npm i -g @qcqx/lattice-cli

MIT
Local-first
No telemetry
Agent-agnostic

LOCAL · ~/.lattice

THE GAP

AI starts from zero.
Every time.

A new repo. A new session. A new teammate. A new agent. The context is rebuilt from scratch, then thrown away.

New repo

Conventions live in code, docs and someone’s head.

New session

Decisions disappear into chat scrollback.

New teammate

The same questions, boundaries and mistakes.

New agent

Every tool has its own context, disconnected from the rest.

WORKFLOW / END TO END

One task. A full loop.

Install the CLI once. Then run the whole workflow from your agent — start, load context, record decisions, archive, and distill a spec. The next session starts with the memory already in place.

01 / INSTALL ONCE

npm i -g @qcqx/lattice-cli

Node.js 18+ · no account · local files

02 / CALL IT FROM YOUR AGENT

lattice:task:startAsk your agent…

Type / or @ at the start of your agent input to invoke it; the CLI reads and writes ~/.lattice underneath.

agent · acme-portallocal · simulated

lattice:task:startContinue auth-guard. Keep the public API contract unchanged.

ltc task start auth-guard

task/auth-guard · in_progress

Lattice agent

Loaded the task and its memory. I’ll read the relevant specs before touching code.

lattice:task:startContinue auth-guard. Keep the public API contract unchanged.

ltc task start auth-guard

task/auth-guard · in_progress

Lattice agent

Loaded the task and its memory. I’ll read the relevant specs before touching code.

ltc context --task auth-guard

3 specs · 2 project relations · 4 checkpoints

Lattice agent

The portal still keeps a token in localStorage. The API already supports HttpOnly cookies.

Lattice agent

I’ll migrate the login guard and preserve the existing API envelope.

Move tokens out of the browser. Let the API own rotation.

ltc task checkpoint auth-guard --type decision \
  --title "Move tokens to HttpOnly cookies"

checkpoint · decision

Lattice agent

Plan set: the API writes an HttpOnly cookie; the portal keeps only the profile in memory.

decision

Move tokens to HttpOnly cookies

The portal will not read or persist an access token.

ltc task checkpoint auth-guard --type milestone \
  --title "Login guard migrated"

checkpoint · milestone

Lattice agent

milestone

Login guard migrated

Cookie path, logout and redirect are covered by tests.

No localStorage fallback, even for legacy clients. That is a hard constraint.

ltc task checkpoint auth-guard --type correction \
  --title "Removed localStorage fallback"

checkpoint · correction

Lattice agent

Removed the fallback. The portal no longer reads or writes tokens.

Lattice agent

This correction is now part of the task memory.

correction

Removed localStorage fallback

The portal reads the session only through the API.

lattice:task:archiveArchive auth-guard and leave the reusable experience behind.

ltc task complete auth-guard && ltc task archive auth-guard

task archived · summary written

Lattice agent

Archived. The auth flow changed enough to be reusable, so I’ll distill it into a project spec.

summary

Cookie session model adopted

The auth guard, logout and rotation path are documented.

lattice:task:startContinue auth-guard. Keep the public API contract unchanged.

ltc task start auth-guard

task/auth-guard · in_progress

Lattice agent

Loaded the task and its memory. I’ll read the relevant specs before touching code.

ltc context --task auth-guard

3 specs · 2 project relations · 4 checkpoints

Lattice agent

The portal still keeps a token in localStorage. The API already supports HttpOnly cookies.

Lattice agent

I’ll migrate the login guard and preserve the existing API envelope.

Move tokens out of the browser. Let the API own rotation.

ltc task checkpoint auth-guard --type decision \
  --title "Move tokens to HttpOnly cookies"

checkpoint · decision

Lattice agent

Plan set: the API writes an HttpOnly cookie; the portal keeps only the profile in memory.

decision

Move tokens to HttpOnly cookies

The portal will not read or persist an access token.

ltc task checkpoint auth-guard --type milestone \
  --title "Login guard migrated"

checkpoint · milestone

Lattice agent

milestone

Login guard migrated

Cookie path, logout and redirect are covered by tests.

No localStorage fallback, even for legacy clients. That is a hard constraint.

ltc task checkpoint auth-guard --type correction \
  --title "Removed localStorage fallback"

checkpoint · correction

Lattice agent

Removed the fallback. The portal no longer reads or writes tokens.

Lattice agent

This correction is now part of the task memory.

correction

Removed localStorage fallback

The portal reads the session only through the API.

lattice:task:archiveArchive auth-guard and leave the reusable experience behind.

ltc task complete auth-guard && ltc task archive auth-guard

task archived · summary written

Lattice agent

Archived. The auth flow changed enough to be reusable, so I’ll distill it into a project spec.

summary

Cookie session model adopted

The auth guard, logout and rotation path are documented.

lattice:spec:updateDistill the login changes into a project spec.

ltc spec init session-auth.md

spec/session-auth · project scope

Lattice agent

Distilled session-auth with the cookie boundary, rotation rule and test evidence.

Lattice agent

The next session that touches login will start with this context already in place.

Autoplay is only a demo; the real CLI reads and writes your local state.Read the quick start

THREE LAYERS

Memory, workflow, access.

Not another chat window. A way to make the work itself reusable.

01Memory

Memory layer

Specs, tasks, decisions and experience become typed, searchable artifacts.

Layered specs
Tasks & checkpoints
Project relations
RAG search
Cross-session experience

02Workflow

Workflow layer

Read before work, record while working, distill when archiving.

Read at start
Record in flight
Distill at archive
Reuse across projects

03Access

Access layer

Local files are the source of truth. CLI, Web, VS Code and any command-capable agent can read them.

CLI
Web workbench
VS Code
Dual-track sync
Agent agnostic

THE WORKBENCH

The workbench is the proof.

The real web workbench, running on mocked data. No login, no backend, no network requests.

Open the live demo

LOCAL-FIRST

Your memory stays yours.

Everything lives as plain files in ~/.lattice. No telemetry, no forced cloud, optional Git sync.

FAQ

Is my data uploaded?

No. Lattice writes to ~/.lattice by default. Data leaves your machine only when you explicitly enable Git sync.

Which AI clients are supported?

Any agent that can run a CLI command. Lattice does not lock memory into one model or client.

How is this different from a wiki or issue tracker?

Lattice models the engineering process — specs, tasks, decisions and checkpoints — in one structure that agents can read directly.

Is it free? What runtime does it need?

MIT open source and free to use. The CLI needs Node.js; the web workbench is a browser UI over the same local data.

GET STARTED

Start with the repo you are in.

Install the CLI, initialize local memory, then continue in the next session.

Read the docs GitHub

Above the repo.Beyond the session.

AI starts from zero.Every time.

New repo

New session

New teammate

New agent

One task. A full loop.

Memory, workflow, access.

Memory layer

Workflow layer

Access layer

The workbench is the proof.

Your memory stays yours.

FAQ

Start with the repo you are in.

AI starts from zero.
Every time.