feat: consolidate agent execution stack
This commit is contained in:
-Puter
+28
-11
@@ -148,17 +148,32 @@ bun run dev:server
|
||||
|
||||
This watches and publishes functions to the configured Convex cloud development deployment.
|
||||
|
||||
### 2. Start Rivet Engine
|
||||
### 2. Start the whole stack
|
||||
|
||||
The installed RivetKit 2.3.9 package supplies the platform-specific `rivet-engine` binary. Start it with:
|
||||
The root `dev` script starts Rivet Engine, the AgentOS registry runner, Convex, Flue agents, and the web app in one terminal:
|
||||
|
||||
```bash
|
||||
./node_modules/.pnpm/@rivetkit+engine-cli-*/node_modules/@rivetkit/engine-cli-*/rivet-engine start
|
||||
pnpm dev
|
||||
```
|
||||
|
||||
For phone or Tailscale-device access, start the stack with the web server bound to all interfaces:
|
||||
|
||||
```bash
|
||||
pnpm dev:tailscale
|
||||
```
|
||||
|
||||
### 3. Start Rivet Engine
|
||||
|
||||
If you prefer separate terminals, start the engine from the agents package:
|
||||
|
||||
```bash
|
||||
cd packages/agents
|
||||
bun run dev:engine
|
||||
```
|
||||
|
||||
There must be exactly one local engine listening on `127.0.0.1:6420`. Do not start a second engine, and do not use `npx rivetkit dev`; that command is unavailable in the installed version.
|
||||
|
||||
### 3. Start the AgentOS registry runner
|
||||
### 4. Start the AgentOS registry runner
|
||||
|
||||
```bash
|
||||
cd packages/agents
|
||||
@@ -167,21 +182,21 @@ bun run runner
|
||||
|
||||
The runner registers the AgentOS workspace actor with Rivet Engine. Keep it running whenever a coding attempt or issue-to-PR request may execute.
|
||||
|
||||
### 4. Start Flue agents
|
||||
### 5. Start Flue agents
|
||||
|
||||
For laptop-only access:
|
||||
|
||||
```bash
|
||||
bun run dev:agents -- --port 3585
|
||||
pnpm dev:agents
|
||||
```
|
||||
|
||||
For Convex callbacks or access from another device, bind Flue to all interfaces:
|
||||
|
||||
```bash
|
||||
bun run dev:tailscale:agents -- --port 3585
|
||||
pnpm dev:tailscale:agents
|
||||
```
|
||||
|
||||
Always pass port `3585`; the Flue CLI defaults to `3583`, but the current Zopu configuration and Convex environment use `3585`.
|
||||
The dev scripts already use port `3585`; the Flue CLI defaults to `3583`, but the current Zopu configuration and Convex environment use `3585`.
|
||||
|
||||
If the shell already exports remote Rivet values, shell values override `.env`. Start Flue with explicit local values:
|
||||
|
||||
@@ -191,18 +206,20 @@ RIVET_PUBLIC_ENDPOINT=http://127.0.0.1:6420 \
|
||||
bun run dev:tailscale:agents -- --port 3585
|
||||
```
|
||||
|
||||
### 5. Start the web application
|
||||
### 6. Start the web application
|
||||
|
||||
If you are not using the root `dev` script, start the web app separately.
|
||||
|
||||
For laptop-only access:
|
||||
|
||||
```bash
|
||||
bun run dev:web
|
||||
pnpm dev:web
|
||||
```
|
||||
|
||||
For phone or other Tailscale-device access:
|
||||
|
||||
```bash
|
||||
bun run dev:tailscale:web
|
||||
pnpm dev:tailscale:web
|
||||
```
|
||||
|
||||
Open `http://localhost:5173`, or `http://<tailscale-ip>:5173` when using the Tailscale command.
|
||||
|
||||
+19
-19
@@ -5,7 +5,7 @@
|
||||
> **Status:** Working source of truth
|
||||
> **Audience:** product, design, engineering, agents
|
||||
> **Normative words:** **MUST** = required, **SHOULD** = default, **MAY** = optional
|
||||
> **Product boundary:** this file defines *what and why*, not implementation details.
|
||||
> **Product boundary:** this file defines _what and why_, not implementation details.
|
||||
|
||||
## 1. Thesis
|
||||
|
||||
@@ -35,7 +35,7 @@ Technical founders and small engineering teams working in one Git repository.
|
||||
```text
|
||||
Project chat
|
||||
→ actionable Signal
|
||||
→ approved Work Definition
|
||||
→ ready Work Definition
|
||||
→ lightweight Design Packet
|
||||
→ vertical slices
|
||||
→ isolated coding run
|
||||
@@ -90,7 +90,7 @@ A Work card is the durable, inspectable representation of one desired outcome. I
|
||||
All decisions requiring a human are first-class objects:
|
||||
|
||||
- clarify intent;
|
||||
- approve definition/design;
|
||||
- definition/design persist automatically;
|
||||
- grant permission;
|
||||
- select an alternative;
|
||||
- review a slice;
|
||||
@@ -249,18 +249,18 @@ Canonical knowledge updates require review.
|
||||
|
||||
High-quality software is evaluated across:
|
||||
|
||||
| Dimension | Required question |
|
||||
|---|---|
|
||||
| Correctness | Does behavior satisfy the accepted criteria? |
|
||||
| Regression safety | Did existing behavior remain valid? |
|
||||
| Maintainability | Does the change preserve understandable boundaries? |
|
||||
| Security | Are permissions, secrets, data, and dependencies safe? |
|
||||
| Reliability | Are failures and edge cases handled? |
|
||||
| Operability | Can it be deployed, observed, debugged, and rolled back? |
|
||||
| Performance | Are expected resource limits preserved? |
|
||||
| UX | Does the actual user path work? |
|
||||
| Traceability | Can claims be tied to evidence and revisions? |
|
||||
| Reversibility | Can risk be disabled or rolled back? |
|
||||
| Dimension | Required question |
|
||||
| ----------------- | -------------------------------------------------------- |
|
||||
| Correctness | Does behavior satisfy the accepted criteria? |
|
||||
| Regression safety | Did existing behavior remain valid? |
|
||||
| Maintainability | Does the change preserve understandable boundaries? |
|
||||
| Security | Are permissions, secrets, data, and dependencies safe? |
|
||||
| Reliability | Are failures and edge cases handled? |
|
||||
| Operability | Can it be deployed, observed, debugged, and rolled back? |
|
||||
| Performance | Are expected resource limits preserved? |
|
||||
| UX | Does the actual user path work? |
|
||||
| Traceability | Can claims be tied to evidence and revisions? |
|
||||
| Reversibility | Can risk be disabled or rolled back? |
|
||||
|
||||
### Completion rule
|
||||
|
||||
@@ -283,7 +283,7 @@ The implementation worker MUST NOT be the sole authority on completion.
|
||||
Builder → candidate output
|
||||
Verifier → independent evidence
|
||||
Resolver → completion decision
|
||||
Human → policy-defined approvals
|
||||
Human → merge/release authorization
|
||||
```
|
||||
|
||||
### Risk lanes
|
||||
@@ -309,7 +309,7 @@ definition → combined design → 1–3 slices → verify → review → PR
|
||||
Auth, billing, permissions, migrations, shared infrastructure, destructive operations.
|
||||
|
||||
```text
|
||||
definition approval → architecture approval → program-design approval
|
||||
definition → design → ready → merge/release
|
||||
→ one slice at a time → staged release → observation/rollback gate
|
||||
```
|
||||
|
||||
@@ -356,8 +356,8 @@ Humans should spend attention on high-leverage decisions, not supervise tool cal
|
||||
|
||||
Preferred gates:
|
||||
|
||||
- Work Definition approval;
|
||||
- Design Packet approval for standard/critical work;
|
||||
- Work Definition (no approval gate);
|
||||
- Design Packet (no approval gate);
|
||||
- slice review when risk requires it;
|
||||
- merge/release approval;
|
||||
- resolution of ambiguity or policy exceptions.
|
||||
|
||||
+5
-7
@@ -198,9 +198,7 @@ All external/model payloads MUST be decoded with schemas at boundaries.
|
||||
```text
|
||||
Proposed
|
||||
→ Defining
|
||||
→ AwaitingDefinitionApproval
|
||||
→ Designing
|
||||
→ AwaitingDesignApproval
|
||||
→ Ready
|
||||
→ ExecutingSlice
|
||||
→ VerifyingSlice
|
||||
@@ -242,7 +240,7 @@ Initial central aggregate:
|
||||
- Design Packet and versions;
|
||||
- slice/step graph;
|
||||
- Resolver state;
|
||||
- approvals/questions;
|
||||
- questions;
|
||||
- artifact references;
|
||||
- result.
|
||||
|
||||
@@ -425,7 +423,7 @@ HarnessRuntime
|
||||
|
||||
v0 selects one harness. Prefer mature coding harnesses for repository exploration/edit/test loops; use custom FLUE agents for product-specific reasoning.
|
||||
|
||||
Zopu owns Work, branches, worktrees, budgets, approvals, artifacts, and completion. Harness owns one bounded implementation loop.
|
||||
Zopu owns Work, branches, worktrees, budgets, artifacts, and completion. Harness owns one bounded implementation loop.
|
||||
|
||||
## 10. Runtime strategy
|
||||
|
||||
@@ -580,7 +578,7 @@ Never create a “verified PR” from a different SHA than the verified candidat
|
||||
Review package:
|
||||
|
||||
- original intent;
|
||||
- approved definition/design;
|
||||
- current definition/design;
|
||||
- slice narrative;
|
||||
- meaningful diffs;
|
||||
- screenshots/video;
|
||||
@@ -608,7 +606,7 @@ Production release requires explicit policy, rollout plan, health signals, and r
|
||||
- no long-lived model/Git secrets in workspace files;
|
||||
- network egress policy;
|
||||
- artifact access authorization;
|
||||
- immutable audit trail for approvals;
|
||||
- immutable audit trail for all Work events;
|
||||
- tool allowlist per Kit;
|
||||
- destructive tools denied by default;
|
||||
- merge/deploy human-gated initially;
|
||||
@@ -663,7 +661,7 @@ Keep Cube control APIs private; expose only authorized preview paths. Rivet and
|
||||
The architecture is proven when one real repository supports:
|
||||
|
||||
```text
|
||||
message → Signal → approved Work → approved Design Packet
|
||||
message → Signal → proposed Work → ready Work
|
||||
→ one slice → isolated harness run → independent verification
|
||||
→ verified commit → real PR → human response/resume
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user