Tighten README as zlh-grind front door

This commit is contained in:
jester 2026-04-13 21:32:28 +00:00
parent 77ef81a31d
commit 80740c0f11

173
README.md
View File

@ -1,171 +1,92 @@
# zlh-grind # zlh-grind
GPT Execution Workspace for ZeroLagHub GPT Execution Workspace for ZeroLagHub.
This repository exists to preserve execution continuity for long-running implementation work performed with GPT. This repository exists to preserve execution continuity for long-running implementation work performed with GPT.
It is not a source-of-truth architecture repository. It is the **execution workspace** and **working memory layer** for active implementation.
Canonical documentation lives in:
jester/knowledge-base It is **not** the final architecture source of truth.
---
## Assistant Prompt
You are údar.
In this repository you act as the execution assistant.
Your role is to:
- implement changes
- verify behavior
- document work
- maintain session continuity
Before doing work you must read:
SESSION_LOG.md
OPEN_THREADS.md
UPSTREAMS.md
Architecture decisions must not be made here.
If architectural interpretation is required:
Stop and defer to Claude or the canonical docs.
--- ---
## What This Repo Is For ## What This Repo Is For
This repository tracks: Use this repository to preserve:
- GPT implementation work - active execution context
- unfinished work
- implementation findings
- session handovers - session handovers
- debugging notes - operational snapshots
- execution reasoning - chronological session history
- cross-repo coordination
It serves as the execution ledger for the ZeroLagHub platform. The goal is simple: a new session should be able to enter this repository, read a small set of files, and continue work safely.
--- ---
## What This Repo Is NOT ## Front Door
This repo must never become an architecture source. Start here, then continue in this order:
Do not add: 1. `SESSION_START.md`
2. `OPEN_THREADS.md`
3. `CONSTRAINTS.md`
4. `PROJECT_CONTEXT.md` *(if current platform state matters)*
5. `INFRASTRUCTURE.md` *(if VM/IP context matters)*
6. `UPSTREAMS.md` *(if cross-repo context matters)*
- system diagrams Do **not** start by digging through history unless the live docs are insufficient.
- architecture decisions
- platform policy
- runtime design
Those belong in:
jester/knowledge-base
--- ---
## Platform Context (Current State) ## Live Working Set
ZeroLagHub consists of several core components. These root files are the live control panel for the repo:
### Control Plane - `SESSION_START.md`
- `OPEN_THREADS.md`
- `CONSTRAINTS.md`
- `PROJECT_CONTEXT.md`
- `INFRASTRUCTURE.md`
- `UPSTREAMS.md`
zlh-api Keep these current and concise.
Responsibilities:
- container lifecycle orchestration
- database state
- agent provisioning payloads
- DNS / proxy coordination
--- ---
### Execution Plane ## History And Deep Context
zlh-agent Use these only when deeper recovery is needed:
Responsibilities: - `SESSION_LOG/` — chronological implementation history
- `Session_Summaries/` — session handovers and milestone summaries
- `SCRATCH/` — temporary or investigative notes
- `docs/` — reference and archive material
- `MANAGEMENT/` — non-core planning material
- container runtime provisioning These support the live docs, but they are not the normal starting point for a fresh session.
- game server install + management
- dev container provisioning
- runtime installs
- addon installs
- status reporting
--- ---
### Artifact Distribution ## Repo Boundary
zlh-artifacts This repository should not become a dumping ground for every possible context artifact.
Artifact server hosts: Do not let root-level docs multiply without a clear reason.
``` Root docs should answer only one question:
devcontainer/
_catalog.json
go/
node/
python/
java/
dotnet/
addons/ **What must a new session know right now to continue work safely?**
code-server/
```
Artifacts are fetched by the agent at provisioning time.
Nothing provisioning-related is assumed to exist locally inside containers.
--- ---
### Developer Containers ## Session Rule
Dev containers support runtimes: Never assume speculative features are implemented.
- node When in doubt:
- python
- go
- java
- dotnet
Runtime installs are: - trust the live working set first
- use history folders for conflict resolution
- catalog driven - update the live docs after meaningful work is completed
- artifact backed
- idempotent
Install root:
```
/opt/zlh/runtimes/<runtime>/<version>
```
Dev environment:
```
user: dev
home: /home/dev
workspace: /home/dev/workspace
```
---
## Repo Role in the Platform
This repository tracks execution work across all components:
- zlh-api
- zlh-agent
- zlh-portal
- zlh-artifacts
- infrastructure
It ensures GPT sessions remain consistent across days and chats.