graphlemon: auto-commit uncommitted changes for 77def7e3-7be4-4dee-8657-3a65bd9d…

…6f22-main-checkout-drift

graphlemon: auto-commit uncommitted changes for 77def7e3-7be4-4dee-8657-3a65bd9d…
…6f22-main-checkout-drift
graphlemon
1 parent 68055d13
Showing 1 changed file with 53 additions and 17 deletions
CLAUDE.md
@@ -8,10 +8,10 @@ Read this first, then follow the pointers below — do not start writing code be
 ## What this is
  
 **graphlemon** is a Level 5 autonomous "lights-out software factory": a two-layer Organizer Agent
-architecture (Org Graph = fixed Planner→Coder→Validator; Work Graph = dynamic per-task execution
-graph) that drives real software development end-to-end, backed entirely by Claude Code ACP
-(`claude -p` non-interactive calls) — there is no Hermes CLI execution backend in this project
-(decision, 2026-07-29, see `docs/sdd/05-实施约束与依赖.md` §5.3).
+architecture (Org Graph = fixed Planner→Planner-Reviewer→Coder→Validator; Work Graph = dynamic
+per-task execution graph) that drives real software development end-to-end, backed entirely by
+Claude Code ACP (`claude -p` non-interactive calls) — there is no Hermes CLI execution backend in
+this project (decision, 2026-07-29, see `docs/sdd/05-实施约束与依赖.md` §5.3).
  
 The authoritative spec is `docs/sdd/` (00-06 + `docs/sdd/sdd-mvcp-contract.json`), generated via
 the MVCP (Model/View/Controller/Process) methodology from `docs/graphlemon_architecture.md`.
@@ -28,10 +28,11 @@ Unit from U-001 through U-043 has a matching commit, plus many `U-0XX fix:`/`U-0
 commits for bugs found during real (not mocked) runs, plus a long tail of `graphlemon: <artifact
 type> for task <uuid>` / `graphlemon: auto-commit uncommitted changes for <id>` / `graphlemon:
 merge <id>` commits — those are graphlemon **actually self-hosting**: running its own
-Planner→Coder→Validator loop against its own repo (`target_folder_path` == this checkout,
-`src/paths.is_self_target()`), with the Deploy Supervisor (`supervisor/`) staging, health-checking,
-and cutting over its own code changes. PH5 (self-modification / auto-rollback) is real and running,
-not future work — see "Two things named Supervisor" below and `supervisor/self_hosting_e2e.py`.
+Planner→Planner-Reviewer→Coder→Validator loop against its own repo (`target_folder_path` == this
+checkout, `src/paths.is_self_target()`), with the Deploy Supervisor (`supervisor/`) staging,
+health-checking, and cutting over its own code changes. PH5 (self-modification / auto-rollback) is
+real and running, not future work — see "Two things named Supervisor" below and
+`supervisor/self_hosting_e2e.py`.
  
 When a `development-plan.md` line and the actual code disagree about what's done, trust the code
 and `git log`, and — if it matters to the task at hand — flag the doc as stale rather than
@@ -41,6 +42,17 @@ during self-hosting runs and how they were fixed (e.g. worktree commits being si
 `memory: project` writes landing on the wrong checkout) — read them before touching
 `supervisor/isolation/`, `src/work_node_run.py`, or anything worktree-related.
  
+Work beyond the original 43 Units is tracked the same `docs/todo/` → `docs/done/` way, not in
+`development-plan.md`: the `planner_reviewer` Org node (a read-only gate that judges whether
+Planner's BRD/PRD/SDD output is real structured content before Coder is allowed to start —
+`roles/planner_reviewer/role.json`, wired into the loop from `src/e2e_pipeline.py` and
+`src/task_execution.py`, task states `reviewing_planner_output`/`planning_brd_prd_sdd`) shipped as
+"Org Graph unification Phase 1" (commit `ea19c7d`); its design doc is still sitting in
+`docs/todo/org-graph-unification-phase1-review-gate-design.md` even though the code is live —
+another instance of code-vs-doc drift, not a sign the feature is unimplemented. Phase 2 (universal
+self-planning + merged graph + dynamic loop_back, `docs/todo/org-graph-unification-phase2-*`) is
+SDD-written but check `git log`/the actual Phase 2 code before assuming it's running.
+
 ## Where to start
  
 1. Read `docs/development-plan.md` for the Phase → Sub-phase → Unit breakdown and the *design*
@@ -91,6 +103,11 @@ No build step, no lint config, no package manager — pure stdlib Python, nothin
  
 # local console (U-007/U-008): backend serves the API, frontend is static no-build HTML/JS
 python3 -m src.backend_server --port 8000   # default --port 0 means OS-assigned (fine for tests, not for browsing)
+
+# frontend/app.js has no framework and no automated-test precedent per the SDD (manual browser
+# verification is the norm), but a few DOM-rendering functions do have plain-Node smoke tests
+# (vm.Context sandboxing, no npm deps) — run individually, there's no aggregate runner:
+node frontend/test_graph_console_smoke.js
 ```
  
 ## Hard constraints (do not relitigate these — they're settled decisions)
@@ -170,16 +187,34 @@ directly; anything worth reusing has already been copied and adapted into this r
 - `docs/wireframes/` — static no-build HTML prototypes for the PH3 console views (`v_*.html`),
   referenced per-page from `docs/sdd/02-V-界面与交互.md` §2.1-2.13; DOM/class names map 1:1 to
   that doc's field lists.
+- `roles/<role_id>/role.json` — the Role Package abstraction (H, 2026-08-06,
+  `docs/done/role-package-abstraction-design.md`): the declarative manifest for each Org node
+  (`skills:`/`model:`/`permissions.tools`/etc., including the `skills:` frontmatter list for
+  that role's `.claude/agents/*.md`). This **replaced** the old hardcoded
+  `src/agent_profile.py::FRONTMATTER`/`_DESCRIPTIONS`/`_MIGRATED_FROM_PROFILE` Python dicts —
+  edit `roles/<role_id>/role.json`, not `agent_profile.py`, to change a role's declared
+  skills/model/tools. `ORG_NODES` is no longer a fixed 3-tuple; `src/agent_profile.py` discovers
+  it by scanning `roles/` for directories containing a `role.json`, so adding a new Org role is
+  one new JSON file, no `schema.py`/`agent_profile.py` edit. `role.json` is JSON (not YAML,
+  despite Skill files using YAML frontmatter) because, unlike Skill frontmatter, this file is
+  parsed by graphlemon's own Python code, not just by Claude Code. `identity.soul_md_path`/
+  `agents_md_path` in each `role.json` still point at the unmoved `agents/<org_node>/SOUL.md`/
+  `AGENTS.md` files below — `role.json` is a reference manifest, not a content copy.
 - `skills/` — the Skill library (architecture doc §7.3): one directory per skill
   (`skills/<name>/SKILL.md` + optional `references/`), migrated/adapted from the Hermes profiles
-  (§9's role mapping) and referenced by name from each Org Agent's `.claude/agents/*.md`
-  `skills:` frontmatter list (`src/agent_profile.py::FRONTMATTER`, the canonical source of that
-  list — edit it there, not by hand-editing the deployed `.claude/agents/*.md`).
-- `.claude/workflows/` — auto-generated, not hand-authored: real Dynamic Workflow scripts written
-  by `src/work_graph_execute.py::write_workflow_script()`/`src/work_graph_orchestrate.py` (one
-  script per Work Node execution) and by `e2e_pipeline.py`'s PRD-consistency check. Version-
-  controlled because it's inside the target repo (self-target case: this repo), but treat the
-  contents as execution artifacts, not source you maintain by hand.
+  (§9's role mapping) and referenced by name from each Org role's `roles/<role_id>/role.json`
+  `skills:` list, which is compiled into the deployed `.claude/agents/*.md` `skills:` frontmatter.
+- `.claude/workflows/` — **historical mechanism, 2026-08 onward**: used to hold auto-generated
+  Dynamic Workflow scripts written by `src/work_graph_execute.py::write_workflow_script()`, one
+  per Work Node execution (`work_graph_orchestrate.py`) plus `e2e_pipeline.py`'s PRD-consistency
+  check. As of the work-graph-node-execution-deblackbox migration (2026-08,
+  `docs/todo/work-graph-node-execution-deblackbox-requirements.md`), production code no longer
+  writes new files here — every call site that used to render a one-off `.js` script purely to
+  get "agent identity + schema-shaped output" now uses `org_node_trigger.
+  trigger_org_node_structured()` (a flat `claude --agent` call + ```json-fence extraction, the
+  same mechanism `work_graph_plan.py::plan_work_graph()` had already validated in production).
+  Files already generated by real self-hosting runs before this migration are kept (execution
+  artifacts, not source you maintain by hand) — this directory just stops growing.
 - `src/` — graphlemon's own backend: `schema.py` (17-table SQLite schema — the original 01-M 15
   entities plus PH5's `deployment`/`deploy_health_signal`), `backend_server.py` (stdlib
   `http.server` HTTP API + WebSocket-ish log/event streaming, no third-party deps), the Org Graph
@@ -198,7 +233,8 @@ directly; anything worth reusing has already been copied and adapted into this r
   `isolated_workspace.py`, `change_manifest.py`, `selective_apply.py`, `workspace_security.py`,
   adapted from graphloop). `supervisor/self_hosting_e2e.py` is the acceptance-scenario glue that
   wires Graph Engine scheduling + Deploy Supervisor into one real self-targeted run.
-- `agents/{coder,planner,validator}/SOUL.md` — original Hermes-profile identity docs, migrated
+- `agents/{coder,planner,planner_reviewer,validator}/SOUL.md` — original Hermes-profile identity
+  docs (`planner_reviewer` added 2026-08, see Org Graph unification note below), migrated
   2026-07-31 (A-2 assumption, "部分成立" — Coder's needed real rewriting to drop a hardcoded
   Feishu API token and a `--dangerously-skip-permissions` self-invocation; Planner/Validator were
   near-verbatim). These are the source-of-truth prose; `.claude/agents/*.md` is the actual