宜博 / lemongraph

Implements docs/todo/dynamic-work-graph-design-skill-design.md. G already
answered FR-2 (how to mark a parallel-eligible node group): no new field
needed -- topological_layers() infers independence purely from
depends_on/edges, so the new Skill's job is just "express real
dependencies honestly, don't add fake ones."

New Skill skills/design-dynamic-work-graph/SKILL.md: the node-boundary /
zero_token-vs-needs_judgment / per-node self-contained task_prompt
methodology, wired into agent_profile.py's FRONTMATTER for coder and
validator (Planner's own doc-chain path is untouched -- FR-4 only names
Coder/Validator).

work_graph_plan.py: new _GENERIC_PROMPT_TEMPLATE + generic_node_prompt_builder(),
used whenever org_node != 'planner'. Planner keeps its existing fixed
brd/prd/sdd/benchmark/... chain (_PROMPT_TEMPLATE) completely unchanged --
zero regression risk to the one real production planning path.

Scoped per the requirements doc's non-goal #1 ("prove the mechanism works,
don't cover every real scenario yet"): does NOT wire into
e2e_pipeline.py::implement_code()'s existing single-node production path.
New tests prove the mechanism itself: a Coder scenario that naturally
splits into 3 independent modules produces a correctly-shaped
graph_manifest, topological_layers() puts all three in one concurrent
layer (ties E directly to G), and generic_node_prompt_builder drives it
through run_graph() to completion.

Full src suite (580 tests) passes with zero regressions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Real incident (2026-08-06): the skill-content migration task and the skill
detail page bug fix were two separate tasks. Neither was asked to verify
that migrated content is actually reachable through the DB-backed lookup
the detail page uses. Both passed their own tests cleanly -- because both
only ever exercised the mechanism against seeded/mocked fixture data, never
checked whether the real producer's real output actually exists in the
real system. The result: the skill detail page returned "not found" for
all 12 real migrated skills, and nobody caught it until a human clicked
through the real console.

qa-task-validation (§8): passing unit tests against seeded fixtures proves
the mechanism is correct given valid input -- it does not prove that input
exists for real. When a feature reads data another task/process was
supposed to have already written, Validator must independently query the
real running system against a real (not newly-created) object.

project-sdd-planning (§10): when a task's acceptance depends on another
task's real output, the Benchmark must name a real, specific object as the
acceptance anchor, not just describe the mechanism.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>