kimminsungandClaude Opus 4.8
a71790070d
Three.js viewer supporting glb/gltf/obj/fbx/dae/ifc/ply via both server (SSR) and drag&drop (CSR) paths. - Streaming OBJ parser (src/viewer/objStream.ts) for files past the V8 max string length (>~1GB text) that OBJLoader can't handle; indexed geometry, per-vertex color from MTL Kd, float64 recenter baked in. - In-viewer float64 recenter (objRecenter.ts) for huge CAD/survey coordinates (~1e8) so float32 vertex buffers keep precision (no cracked faces). - Z-up right-handed world; Y-up formats rotated on load. - OBJ+MTL+texture drag&drop (LoadingManager URL-modifier maps dropped images). - OrbitControls ground-plane panning (road/rail alignment workflow). - UI: Zoom Fit, perspective/orthographic toggle, feature-edge outline. - DoubleSide for CAD OBJ; PLY mesh + point-cloud support. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
44 lines
2.0 KiB
Markdown
44 lines
2.0 KiB
Markdown
---
|
|
name: task-graph
|
|
description: >
|
|
Multi-agent coordination protocol for hmwebviewer. Load when picking up work,
|
|
dispatching agents, or reporting progress. Explains how PLAN.md and PROGRESS.md
|
|
drive parallel agent work and the exact update rules.
|
|
---
|
|
|
|
# hmwebviewer — multi-agent task-graph protocol
|
|
|
|
`PLAN.md` = the backlog (what to do). `PROGRESS.md` = the log (what happened). CLAUDE.md mandates reading both on every agent start.
|
|
|
|
## Picking a task
|
|
1. Read `PLAN.md` task tables.
|
|
2. Find rows with status `todo` whose entire `depends_on` list is `done`.
|
|
3. Among those, pick by wave (see PLAN.md "Parallelization map") or by the task's `Agent` column.
|
|
4. Before working: flip status to `in_progress(@yourname)` in PLAN.md.
|
|
|
|
## Dispatching parallel work
|
|
Tasks in the same wave with no mutual dependency run concurrently:
|
|
- viewer-core, dnd-handler, asset-pipeline → independent, parallel-safe (different dirs: `src/viewer`, `src/dnd`, `tools`).
|
|
- hydration depends on viewer-core signals → run after.
|
|
- reviewer → last / on-demand.
|
|
|
|
Spawn each via the Agent tool in ONE message with multiple calls so they run concurrently. Pass every agent: task ID, file scope, acceptance criteria, pointer to PLAN.md.
|
|
|
|
## Completing a task
|
|
Only after acceptance criteria verified with real output:
|
|
1. Flip the PLAN.md row to `done`.
|
|
2. Append a `## YYYY-MM-DD — <task>` entry to PROGRESS.md top of Work log (Did / Result / Next / Blocker).
|
|
3. If a decision was made, add to PROGRESS.md "Decision log" and (if durable) to user memory.
|
|
|
|
## Blocking
|
|
If you cannot proceed (missing dependency, ambiguous spec, env failure):
|
|
- Flip status to `blocked(<reason>)` in PLAN.md.
|
|
- Append PROGRESS.md entry with the blocker.
|
|
- Stop. Do not guess around a real blocker.
|
|
|
|
## Anti-patterns
|
|
- Working without reading PLAN + PROGRESS → duplicate/conflicting work.
|
|
- Marking done without verification → silent regressions.
|
|
- Editing outside your task's file scope → steps on another agent.
|
|
- Creating parallel loaders/state instead of using the shared singleton → crashes.
|