From ecd06689064bf8f34c045a9a199bdbd352523ded Mon Sep 17 00:00:00 2001 From: graphlemon Date: Thu, 13 Aug 2026 15:36:58 +0800 Subject: [PATCH] graphlemon: auto-commit uncommitted changes for 77def7e3-7be4-4dee-8657-3a65bd9d6f22-main-checkout-drift --- CLAUDE.md | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 53 insertions(+), 17 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 085e4ce..38a2bad 100644 --- a/CLAUDE.md +++ b/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: for task ` / `graphlemon: auto-commit uncommitted changes for ` / `graphlemon: merge ` 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.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.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//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//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.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 -- libgit2 0.21.4