54 lines
3.0 KiB
Markdown
54 lines
3.0 KiB
Markdown
# Product
|
|
|
|
<!-- impeccable:product-schema 1 -->
|
|
|
|
## Platform
|
|
|
|
web
|
|
|
|
## Users
|
|
|
|
One person: a developer who runs coding agents on several machines (a mac and a linux laptop) and self-hosts lodge for themselves. They open the admin mostly to read agent-written notes and their history, from a desk and from a phone. Anyone may self-host their own instance, but each instance is single-user.
|
|
|
|
## Product Purpose
|
|
|
|
Agent-written files (plans, notes, architecture docs) stay out of git yet follow the repository to every machine, versioned, with no per-project setup and without touching `.gitignore`. The admin is where the owner reads those files, walks their history, sees which machine changed what at which commit of the main repository, brings an old version back, and connects new machines.
|
|
|
|
## Positioning
|
|
|
|
Every revision of the notes is pinned to the commit and branch of the main repository it was written against, so "what did the agent know at commit X" is a lookup, not archaeology. Notes are split into shared ones and ones that follow a git branch.
|
|
|
|
## Operating Context
|
|
|
|
- Repositories are identified by their root commit hash; the display name is the directory name.
|
|
- Files live in spaces: `shared` and `branch:<name>`. Rules come from a `.lodge` file at the repository root.
|
|
- A revision has a per-repo sequence number, the machine that pushed it, a time, the main repository's branch and SHA, and a list of changes (added, modified, deleted).
|
|
- Conflicts resolve by later edit wins; the losing version is kept as its own revision.
|
|
- A machine is connected with a one-time command `curl -fsSL <url>/i/<code> | sh`; the code lives 10 minutes.
|
|
- CLI equivalents exist: `lodge log`, `lodge show`, `lodge status`.
|
|
|
|
## Capabilities and Constraints
|
|
|
|
- Admin scope confirmed by the owner: repository list, file browser per space, revision history with main SHAs, line diff between revisions, restore a file version, delete a repository with its history, list machines and revoke one, add a machine.
|
|
- Login: the `ADMIN_TOKEN` is typed once as a password, the server sets an HttpOnly session cookie.
|
|
- Static SvelteKit build (adapter-static, SPA fallback) served by the Go server; no SSR.
|
|
- Files are mostly markdown and plain text, at most 5 MB each.
|
|
- The server URL is never hardcoded; it comes from `PUBLIC_URL` or the request.
|
|
|
|
## Brand Commitments
|
|
|
|
- Name: lodge, lowercase.
|
|
- Must not look like a generic SaaS dashboard (metric cards, icon sidebar).
|
|
- Must be comfortable on a phone: opening and reading a note from mobile is a real use.
|
|
|
|
## Evidence on Hand
|
|
|
|
No logo, no screenshots, no real users besides the owner. Real data exists only on a running instance; demo data for development is synthetic.
|
|
|
|
## Product Principles
|
|
|
|
- Reading first: the note and its history are the product, management is the margin.
|
|
- Every change answers who, when, and against which commit.
|
|
- Nothing is lost: deletions and losing edits stay reachable.
|
|
- Zero ceremony: one command adds a machine, nothing is configured per project.
|