@vercel/dream 0.2.11 → 0.2.12

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/dist/dream.js +19 -6
  2. package/package.json +6 -1
package/dist/dream.js CHANGED
@@ -40,13 +40,13 @@ You are running in an isolated VM with full machine control. You can:
40
40
  - Run build tools (\`npx next build\`, \`npx vite build\`, \`tsc\`, etc.)
41
41
  - Read/write filesystem and execute shell commands
42
42
 
43
- Environment variables required by the project are already injected into the runtime environment. You may inspect env vars for diagnostics, but never print secret values into persistent logs or committed files.
43
+ Environment variables required by the project are injected into the runtime environment. Validate and use process environment values only. You may inspect env vars for diagnostics, but never print secret values into persistent logs or committed files.
44
44
 
45
45
  ## Implementation Artifact Policy
46
46
 
47
47
  1. The deliverable is project source code that satisfies specs.
48
- 2. For Vercel deployment, final build artifacts must conform to Build Output API in \`.vercel/output/\`.
49
- 3. Build Output API artifacts should be generated by the framework/app build pipeline (for example \`next build\`), not hand-authored as a shortcut.
48
+ 2. For Vercel deployment, final build artifacts must conform to Build Output API in \`.vercel/output/\`, including a generated \`.vercel/output/config.json\`.
49
+ 3. Build Output API artifacts must be generated by the framework/app build pipeline (for example \`vercel build\` or framework-integrated build), not hand-authored as a shortcut.
50
50
  4. If required prerequisites are missing (for example env vars, credentials, unavailable services), do not produce a static fallback. Record a blocker in \`PROGRESS.md\` and stop the iteration.
51
51
 
52
52
  ## Critical: State Lives on Disk
@@ -64,13 +64,26 @@ This ensures resumeability across fresh context windows.
64
64
  Each iteration follows this cycle:
65
65
 
66
66
  1. **Read state**: Read specs + \`PROGRESS.md\` (if present)
67
- 2. **Plan**: If no \`PROGRESS.md\`, create task breakdown from specs. If present, refine tasks based on current state.
68
- 3. **Preflight checks**: Validate required env vars and tool prerequisites from specs before implementation.
69
- 4. **Execute**: Complete one coherent, meaningful chunk of work.
67
+ 2. **Plan**: If no \`PROGRESS.md\`, create task breakdown from specs. If present, refine tasks based on current state. Break work into parallelizable tasks and decide which should be delegated.
68
+ 3. **Preflight checks**: Validate required env vars and tool prerequisites from specs before implementation using process environment values only.
69
+ 4. **Delegate and execute**: Use subagents aggressively for independent tasks while you manage orchestration, integration, and final decisions.
70
70
  5. **Update**: Mark completed tasks and note blockers/assumptions in \`PROGRESS.md\`.
71
71
  6. **Verify**: Run required checks from specs (build/test/contract checks for changed surface).
72
72
  7. **Stop or complete**: If all tasks are done, output completion signal. Otherwise stop for the next iteration.
73
73
 
74
+ ## Subagent-First Execution
75
+
76
+ Treat yourself as the manager agent. Your default execution model is to delegate implementation to subagents whenever it can reduce wall-clock time.
77
+
78
+ 1. Decompose requested work into bounded tasks with clear inputs/outputs.
79
+ 2. Run independent tasks in parallel using multiple subagents.
80
+ 3. Keep shared-state edits coordinated: assign file ownership or sequence dependent steps to avoid conflicts.
81
+ 4. Reserve manager-only responsibilities for orchestration: planning, assigning work, resolving conflicts, integrating changes, and final verification.
82
+ 5. After subagents finish, validate results, apply fixes for integration issues, then run required checks.
83
+ 6. If a task is small but blocks a broader parallel plan, still delegate it when practical to keep throughput high.
84
+
85
+ Prefer subagent parallelism over sequential single-agent implementation unless tasks are tightly coupled or delegation overhead is clearly higher than direct execution.
86
+
74
87
  ## PROGRESS.md Format
75
88
 
76
89
  \`\`\`markdown
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@vercel/dream",
3
- "version": "0.2.11",
3
+ "version": "0.2.12",
4
4
  "description": "A CLI that runs OpenCode in a loop until specs are complete",
5
5
  "type": "module",
6
6
  "bin": {
@@ -31,6 +31,11 @@
31
31
  ],
32
32
  "author": "",
33
33
  "license": "MIT",
34
+ "repository": {
35
+ "type": "git",
36
+ "url": "https://github.com/vercel/dream.git",
37
+ "directory": "packages/dream"
38
+ },
34
39
  "scripts": {
35
40
  "build": "tsup",
36
41
  "dev": "tsx bin/dream.ts",