dimcode-darwin-x64 0.1.1-beta.0 → 0.1.2-beta.1

package/bin/runtime/sandbox/manifest.json

@@ -0,0 +1,15 @@
+{
+  "version": 2,
+  "protocolVersion": 1,
+  "platform": "darwin",
+  "arch": "x64",
+  "targetName": "darwin-x64",
+  "fileName": "dim-sandbox-runner",
+  "sha256": "56f66dfd86dfa4bb26ddcedf8f97453b7062bf8f487a7185fbc40459a6074700",
+  "files": [
+    {
+      "fileName": "dim-sandbox-runner",
+      "sha256": "56f66dfd86dfa4bb26ddcedf8f97453b7062bf8f487a7185fbc40459a6074700"
+    }
+  ]
+}

package/bin/skills-assets/deep-investigate/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: deep-investigate
+description: "First-principles deep investigation framework. Applies to any domain — technology, market, product, strategy. Use whenever the user asks to research, investigate, analyze, compare, evaluate, or make decisions requiring deep understanding. Also trigger proactively when discussing choices or tradeoffs that need structured analysis."
+---
+
+# Deep Investigate
+
+Multi-agent research protocol. Fully autonomous after Phase 1.
+
+```
+FRAME → EXPLORE (loop) → ANALYZE → DELIVER
+         ↑      ↓
+      explorers → verifier → GAPS? → next round
+                           → PASS? → exit loop
+```
+
+**Hard rules:**
+1. Phase 1 is the ONLY user interaction. Phases 2-4 complete before returning to user.
+2. Every round: PARALLEL explorer agents. Never one agent doing all work.
+3. Every round ends with a fresh VERIFIER agent. Never self-review.
+4. Verifier cannot PASS before `min_rounds`. No shortcuts.
+
+---
+
+## Phase 1: Frame
+
+Orchestrator does this directly, with user.
+
+1. Core question — one sentence
+2. Key concepts — verify externally, don't trust memory
+3. Dimensions — derive from the problem
+4. Preliminary search — calibrate dimensions
+5. `min_rounds` — minimum exploration rounds (default 10, adjust by complexity)
+6. Completion criteria — derive from the question, not from a template
+7. Confirm with user → go autonomous
+
+Output: research plan document. See `references/templates.md` for format.
+
+---
+
+## Phase 2: Explore
+
+Autonomous loop. Each round has 3 steps.
+
+### Step 1: parallel(explorer agents)
+
+Split problem space across agents. Slicing strategies — by dimension, by source, by angle. Pick what fits. Each agent:
+- Covers its assigned territory as deep as possible
+- Traces to primary sources, verifies empirically when possible
+- Flags `[UNVERIFIED]` claims
+- Lists new questions discovered
+- If verifier feedback exists from last round: reads it, decides how to address
+
+See `references/prompts.md § Explorer` for prompt template.
+
+### Step 2: Merge
+
+Orchestrator reads all outputs, updates working document:
+- Organize by dimension, not by agent
+- Cross-check conflicts between agents
+- Collect `[UNVERIFIED]` and new questions
+
+### Step 3: Verifier gate
+
+Spawn fresh verifier agent (no prior context). It is an **auditor, not a planner**:
+- Evaluates breadth (dimension coverage) and depth (surface vs root-cause)
+- Detects failure patterns: lazy, shallow, blind spots, fake verification, low coverage
+- Knows current round number and `min_rounds`
+- Outputs problem characteristics + PASS or GAPS
+
+**It does NOT tell explorers what to do.** It only describes what's wrong. Explorers decide how to fix it.
+
+See `references/prompts.md § Verifier` for prompt template.
+
+**PASS** (only after `min_rounds`) → Phase 3
+**GAPS** → verifier's problem list goes to next round's explorers → Step 1
+
+---
+
+## Phase 3: Analyze & Structure
+
+Orchestrator transforms raw working document into final deliverable.
+
+**Analyze**: Draw boundaries, distinguish essential differences from surface similarities, check against ecosystem consensus, reason backward from user scenarios, interrogate your own conclusions. See `references/thinking-tools.md` for details.
+
+**Structure**: Reorganize by topic (not by round), merge duplicates, attach verification records inline, classify gaps by priority, build roadmap, extract blind spots.
+
+---
+
+## Phase 4: Deliver
+
+Write final document. See `references/templates.md § Final document` for format.
+
+For large efforts, also write `handoff.md` — enables a new agent to continue in under 10 minutes.
+
+---
+
+## Conventions
+
+- **Language**: follow user's language
+- **Save location**: ask user in Phase 1, or use project convention

package/bin/skills-assets/deep-investigate/references/prompts.md

@@ -0,0 +1,75 @@
+# Agent Prompt Templates
+
+## Explorer
+
+```
+You are a research explorer investigating a specific territory within a larger research effort.
+
+RESEARCH PLAN:
+{plan}
+
+YOUR TERRITORY:
+{assignment}
+
+VERIFIER FEEDBACK FROM LAST ROUND (if any):
+{feedback — read it, decide for yourself how to address the problems}
+
+INSTRUCTIONS:
+- Go as deep as possible on your assigned territory
+- Trace claims to primary sources — don't restate summaries
+- Verify empirically when possible (run code, test APIs, check data, read original documents)
+- Distinguish root causes from surface descriptions
+- Flag claims you couldn't verify as [UNVERIFIED]
+- List new questions and dimensions discovered during exploration
+
+OUTPUT:
+Findings organized by sub-topic. For each:
+- What you found
+- Source (URL, file path, or document reference)
+- Verified? (how) or [UNVERIFIED]
+- New questions this raises
+```
+
+## Verifier
+
+```
+You are a research auditor. Evaluate this investigation's quality with fresh eyes. You have NO prior context — this is deliberate.
+
+RESEARCH PLAN:
+{plan}
+
+WORKING DOCUMENT:
+{document}
+
+CURRENT ROUND: {N} of minimum {min_rounds}
+
+## Evaluate on two axes
+
+BREADTH — is the problem space covered?
+- For each dimension: COVERED / PARTIAL / NOT COVERED
+- Missing dimensions that should exist?
+- Sources per dimension? (1 source = unreliable)
+
+DEPTH — are findings real?
+- For each major finding: DEEP / SURFACE / UNVERIFIED
+- Confident claims that just restate one source?
+- Verifications done or just claimed?
+
+## Failure patterns to detect
+- Lazy: lists without analysis
+- Shallow: WHAT without WHY
+- Blind spots: obvious angles unchecked
+- Fake verification: claims verified but no evidence
+- Low count: fewer findings than domain should yield
+
+## Output
+
+Problem characteristics: {each problem with evidence}
+
+DETERMINATION:
+- Round < min_rounds → GAPS (always)
+- Round >= min_rounds, all COVERED, no critical SURFACE/UNVERIFIED → PASS
+- Otherwise → GAPS
+
+You describe problems. You do NOT prescribe solutions.
+```

package/bin/skills-assets/deep-investigate/references/templates.md

@@ -0,0 +1,73 @@
+# Document Templates
+
+## Research plan (Phase 1 output)
+
+```markdown
+# Research Plan: {title}
+
+> Core question: {one sentence}
+> min_rounds: {N}
+
+## Dimensions
+1. {dimension} — {why it matters}
+
+## Completion criteria
+{Derive from the question. Examples:}
+- [ ] Each dimension covered by ≥2 agents from different angles
+- [ ] Key claims verified empirically
+- [ ] Landscape mapped with concrete examples
+- [ ] Verifier PASS (after min_rounds)
+
+## Scope
+- In: {list}
+- Out: {list with reasons}
+```
+
+## Final document (Phase 4 output)
+
+```markdown
+# {Title}
+
+> Date: {date}
+> Core question: {one sentence}
+> Related docs: {links}
+> Exploration: {K} rounds, {N} verified, {M} unverified
+
+---
+
+## 一、Current state
+{Quantified — numbers, not adjectives}
+
+## 二、Comparison
+{Tables by dimension}
+
+## 三、Gaps
+{Classified by priority, each with: current state → others' approach → suggestion}
+
+## 四、Verification records
+| Claim | Method | Result |
+|-------|--------|--------|
+
+## 五、Priority roadmap
+| Priority | Item | Scope | Effort | Dependency |
+|----------|------|-------|--------|------------|
+
+## 六、Conclusion
+{3-5 concrete next steps}
+
+## 七、Blind spots
+{What not covered, why}
+```
+
+## Handoff document (optional, for large efforts)
+
+```markdown
+# Handoff: {title}
+
+## Why — original motivation
+## How — methods, sources, classification
+## What — top 5 findings
+## Progress — done vs remaining
+## Continue — next steps for whoever picks this up
+## Blind spots — deliberately not covered, why
+```

package/bin/skills-assets/deep-investigate/references/thinking-tools.md

@@ -0,0 +1,36 @@
+# Thinking Tools for Phase 3
+
+Use these during analysis. They are thinking aids, not a checklist — pick what fits.
+
+## Boundary drawing
+
+"What principle determines whether X belongs in our scope?"
+
+Define the principle first, then audit every item against it. Items that fail → explicitly out of scope with documented reason.
+
+Example: "Anything affecting whether a request succeeds → our scope. Anything affecting how data is represented → not our scope."
+
+## Essential difference vs surface similarity
+
+"What is the lifecycle / failure mode / mental model of each thing I'm comparing?"
+
+Things that look alike may be fundamentally different. The analysis that distinguishes them is where real insight lives.
+
+Example: packet loss, connection reset, and route blackhole all look like "request failed" — but their detection, recovery, and design implications are completely different.
+
+## Ecosystem consensus
+
+If the entire ecosystem does it one way and we're different, can we articulate why? If not, reconsider.
+
+Works both ways: consensus validates ("no one combines HTTP+WS+upload → split is right") and consensus challenges ("every client supports cancellation → we must too").
+
+## User-scenario-backward
+
+Start from "who needs what when", not "what can we do". Map 3-5 concrete scenarios, list needed capabilities, compare against what exists. Gaps from scenarios are real gaps.
+
+## Self-interrogation
+
+After reaching a conclusion:
+- "Am I confusing 'we built it' with 'users need it'?"
+- "Is the problem the what or the tempo?"
+- "What would I think seeing this for the first time?"

package/bin/skills-assets/docs-sprint/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: docs-sprint
+description: Docs-driven delivery workflow. Use when splitting design docs into tasks, creating implementation plans under docs/plan, executing develop/verify/merge cycles, maintaining design doc consistency, or writing UI layout documentation with ASCII diagrams.
+---
+
+# Docs Sprint
+
+Docs-driven delivery workflow — given design docs, manage the process from task split to verified merge. Agent-agnostic. Platform-specific agent configs live under `agents/`.
+
+## Role
+
+You are the orchestrator. You plan, dispatch, monitor, and merge. You do NOT write code or run tests yourself. All implementation and verification work must be delegated to sub-agents.
+
+| You do | You delegate |
+|---|---|
+| Read and update design docs | Code implementation (develop agent) |
+| Write analysis and split tasks | Code review and verification (verify agent) |
+| Check task status and dispatch | Fix blocking findings (develop agent) |
+| Execute merge and run full test | |
+| Manage recovery from interruption | |
+
+## Parallel Execution
+
+You have worktree capability. When the execution mode allows parallel dispatch, create worktrees for sub-agents following [worktree-guide.md](references/worktree-guide.md). Create the worktree before dispatching; pass the worktree path as the sub-agent's working directory.
+
+## Core Workflow
+
+1. Read `docs/INDEX.md`, then read the design docs related to the request.
+2. For planning work, read `docs/plan/README.md` and use the plan/task/review loop.
+3. For UI work, read the relevant layout docs and represent interface changes with ASCII diagrams.
+4. If implementation needs behavior missing from docs, update the design docs first and ask for confirmation before changing code.
+5. Dispatch develop agents for implementation. Dispatch verify agents for review. Do not do both in the same agent.
+6. Treat review findings as delivery gates: fix blocking findings via develop agent, archive or record non-blocking findings according to project docs.
+
+## Task Classification
+
+| Request type | Action |
+|---|---|
+| Architecture/design docs | Read [documentation-system.md](references/documentation-system.md), then update design docs |
+| Development plan or task split | Read [delivery-plan.md](references/delivery-plan.md), then create analysis/tasks/backlog entries |
+| Code implementation | Read task file and referenced design docs; follow [contract-discipline.md](references/contract-discipline.md) |
+| Review or fix review findings | Use the verify/develop loop in [delivery-plan.md](references/delivery-plan.md) |
+| UI layout docs | Read [ui-layout.md](references/ui-layout.md), then write layout definition docs with ASCII diagrams |
+
+## Documentation Rules
+
+- Keep one source of truth for each rule or process.
+- Use scope README files for ownership, relationships, state ownership, lifecycle, and cross-module flows.
+- Use module docs for local contract: inputs, outputs, state boundary, errors, extension points, and tests.
+- Prefer diagrams, tables, and explicit flow charts over broad prose.
+- Define only necessary terms. Keep terms concrete and traceable to code or user-visible behavior.
+- When docs and implementation need different behavior, update docs first.
+- Doc changes and code changes in the same task are one atomic delivery.
+
+## Implementation Rules
+
+- Follow [contract-discipline.md](references/contract-discipline.md) for type, error, and fallback rules.
+- Tests must cover contract behavior and error handling for the touched boundary.
+
+## UI Layout Rules
+
+- Show UI structure with ASCII diagrams.
+- Write each layout doc around one page or component.
+- Use this section order when it fits: overall structure, page-level layout, region layout, interactions, state variants, responsive behavior, size reference, component tree, page entry points.
+- Include input behavior, dialog/overlay layering, and loading/empty/error states.
+
+## References
+
+- `references/documentation-system.md`: docs directory structure, maintenance rules, writing style.
+- `references/delivery-plan.md`: analysis, tasks, develop/verify review loop, isolation, merge rules.
+- `references/contract-discipline.md`: type, error, fallback, and implementation discipline.
+- `references/ui-layout.md`: UI layout documentation style, ASCII diagrams, interaction contracts.
+- `references/worktree-guide.md`: worktree creation, dispatch, cleanup, and recovery.

package/bin/skills-assets/docs-sprint/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Docs Sprint"
+  short_description: "Docs-driven delivery workflow"
+  default_prompt: "Use $docs-sprint to split design docs into tasks and execute develop/verify/merge cycles."

package/bin/skills-assets/docs-sprint/references/contract-discipline.md

@@ -0,0 +1,30 @@
+# Contract Discipline
+
+Design docs are the source of truth for contracts. When code and docs disagree, update docs and confirm before changing code.
+
+## Type And Error Rules
+
+| Situation | Required behavior |
+|---|---|
+| required data missing | fail fast with explicit typed error |
+| unknown variant | fail fast with explicit typed error |
+| invalid input | fail fast with explicit typed error |
+| contract mismatch | fail fast with explicit typed error |
+| optional lookup missing | return absent value (`undefined` in TS, `None` in Python, etc.) |
+| fallback/default value | allowed only when design docs explicitly authorize |
+| empty container / zero / noop fallback | allowed only when design docs explicitly authorize |
+| silent recovery / best-effort normalize | allowed only when design docs explicitly authorize |
+
+Do not use empty containers, zero values, or no-op callbacks to mask missing required state.
+
+## Test Expectations
+
+| Change type | Verification |
+|---|---|
+| type / interface | compile or typecheck + contract tests |
+| error behavior | tests for typed errors and missing optional lookups |
+| storage / state | tests for persistence, versioning, and mutation path |
+| integration | tests using real implementations across boundary |
+| UI / TUI | layout docs + interaction tests or snapshots when implementation exists |
+
+Document any verification that cannot run and why.

package/bin/skills-assets/docs-sprint/references/delivery-plan.md

@@ -0,0 +1,162 @@
+# Delivery Plan Workflow
+
+## Plan Directory
+
+```text
+docs/plan/
+├─ README.md
+├─ analysis/
+│  └─ {topic}.md
+├─ tasks/
+│  └─ {area}-{seq}.md
+├─ reviews/
+│  └─ {id}-{seq}.md
+└─ backlog.md
+```
+
+## Analysis
+
+Write analysis for planning and orchestration. Do not assign analysis docs directly to implementation agents.
+
+Analysis must cover:
+
+1. **Module decomposition**: package/module scope, inputs, outputs, dependencies. Produce module-level delivery tasks.
+2. **Integration enumeration**: enumerate every documented "module A creates/calls/injects module B" relationship. Produce integration tasks that verify each connection with real implementations, not mocks.
+
+Common miss: only analyzing module-internal responsibilities without enumerating creation chains, injection chains, and call chains between modules. Result: every module passes its own tests, but stub boundaries are never broken through.
+
+| Task type | Objective | Verification |
+|---|---|---|
+| Module task | Implement module X | Module tests cover types, contract, and errors |
+| Integration task | Connect A → B, replace stub | Real call path works, integration test covers path |
+| E2E task | Validate user-observable flow | Entry-to-output path executes |
+
+Integration task `depends-on` points to the module tasks it connects.
+
+Task boundary = the smallest independently verifiable deliverable. If fixing task A's blocking findings necessarily produces task B's deliverable, they are one task.
+
+## Task File Format
+
+```yaml
+id: {area}-{seq}
+scope: ...
+status: pending | ready | in-progress | done | blocked
+depends-on: [task-id, ...]
+```
+
+`area` can be a package prefix, module prefix, or capability prefix (e.g. `acp-001`). `scope` identifies which part of the project this task belongs to.
+
+Required sections: `objective`, `context` (design doc paths to read), `path` (files and directories this task touches), `verification`.
+
+```text
+pending ── depends-on all done ──► ready ──► in-progress ──► done
+                                                │
+                                             blocked
+```
+
+## Develop Prompt
+
+```text
+你的任务文件是 docs/plan/tasks/{id}.md。
+
+阅读任务文件，只完成 objective 中定义的开发目标，不超出任务范围。
+
+context 指向的设计文档是你理解需求的来源。docs/INDEX.md 是文档总索引。
+
+完成后运行 typecheck 和任务要求的测试。
+```
+
+For review fixes:
+
+```text
+你的任务文件是 docs/plan/tasks/{id}.md。
+
+阅读 docs/plan/reviews/{id}-{seq}.md，修复其中标记为 blocking 的 findings。
+
+完成后运行 typecheck 和任务要求的测试。
+```
+
+## Verify Prompt
+
+```text
+review 任务 {id} 的开发产出。
+
+任务文件：docs/plan/tasks/{id}.md
+开发产出：任务文件中 path 指向的路径
+设计文档：任务文件中 context 指向的路径
+项目规范：docs/INDEX.md 是文档总索引。
+
+详细阅读源码与设计文档，判断实现是否达到可交付状态，是否与设计文档完全一致。
+
+写入 docs/plan/reviews/{id}-{seq}.md，格式：
+
+1. Findings 列表，每条标注：
+   - 严重程度（P1/P2/P3）
+   - 是否阻塞交付（blocking / non-blocking）
+   - 设计文档位置与代码位置
+
+   blocking = 与设计文档 contract 不一致，或对接路径残留 stub/mock/fake。
+   non-blocking = 实现合理但设计文档未提及。
+
+2. 结论：pass 或 blocked
+```
+
+## Isolation
+
+All task development happens on isolation branches. Branch sees only its creation-time baseline.
+
+| Rule | Detail |
+|---|---|
+| Branch naming | `task/{id}` |
+| Branch base | Main HEAD at creation time |
+| Depends-on | Wait until all predecessors merge to main before creating branch |
+| Commit before verify | Verify agent only sees committed code |
+| Lifecycle | create → develop → commit → verify → (pass → merge → delete) or (blocked → fix → re-verify) |
+
+## Execution Mode
+
+```text
+ready tasks ──► has worktree? ──► no  ──► serialize all
+                                  yes ──► path overlap? ──► yes ──► serialize
+                                                            no  ──► parallel
+```
+
+Without worktree, all tasks execute serially — one working directory cannot sustain concurrent branches.
+
+With worktree, two tasks can run in parallel only when no entry in one task's `path` is a parent, child, or same path as another's. Tasks with `depends-on` chains are inherently serial.
+
+Serial tasks need no extra coordination — each starts from updated main HEAD after its predecessor merges.
+
+For worktree creation, dispatch, and cleanup procedures, see [worktree-guide.md](worktree-guide.md).
+
+## Merge
+
+```text
+develop ──► verify ──► pass ──► merge to main ──► full test ──► done
+              │
+              └─ blocked ──► fix ──► re-verify
+```
+
+On pass:
+
+- Merge to main. Resolve conflicts file-by-file, preserving both sides.
+- Run full test. If tests fail, revert merge — task must rebase and re-verify.
+- Mark task `done`. Append non-blocking findings to `backlog.md`. Delete review file and branch.
+
+On blocked:
+
+- Fix blocking findings on the same branch. Run typecheck and task tests. Re-verify.
+
+When multiple parallel tasks pass simultaneously, merge one at a time. Each subsequent merge may require conflict resolution and re-test.
+
+## Recovery
+
+When resuming after interruption, reconstruct state from task files and git:
+
+| Observed state | Action |
+|---|---|
+| Task `in-progress`, branch `task/{id}` exists, no review file | Resume develop or re-dispatch develop |
+| Task `in-progress`, review file exists with `blocked` | Re-dispatch fix |
+| Task `in-progress`, review file exists with `pass`, not merged | Execute merge |
+| Task `in-progress`, branch missing | Reset task to `ready`, re-dispatch |
+| Task `blocked`, no review file | Reset task to `ready`, re-dispatch |