• Root cause traced (docs/implementation-gap-analysis.md): the Benchmark
    document Validator relies on for its verdict was frequently a narrative
    about the work session ("The planner workflow completed and produced a
    Benchmark defining 18 scenarios...") instead of the actual scenarios --
    found via a real skill-detail-page task's benchmark.md, then confirmed
    present since the earliest real self-hosting runs. Validator's own
    judgment was, in practice, resting on thin, sometimes-vacuous prose.
    
    Planner's work graph (brd->prd->sdd->benchmark) extends to
    benchmark->test_dataset->test_script: test_dataset/test_script are always
    present as nodes, but the generating subagent judges per-goal whether a
    real dataset/script applies (many goals, e.g. UI wiring, legitimately
    don't have one -- replying 'N/A: <reason>' is a real, expected answer, not
    a failure). test_script gets a genuinely mechanical verify_fn (real
    py_compile/node --check, not LLM judgment) -- the one node type where an
    objective check is actually possible. All four document prompts also gained
    an explicit anti-narration instruction (only 'brd' had a weaker version of
    this before).
    
    Coder's implementation prompt now receives the real benchmark/dataset/
    script and must make the Planner's real script pass for real, not just
    whatever tests it invents on its own.
    
    Validator gets its own 3-node Work Graph (validator_benchmark ->
    validator_test_dataset -> validator_test_script), generated independently
    from SDD/PRD -- deliberately NOT reusing Coder's or Planner's own copies,
    same reasoning as a held-out eval set vs. the dev set a model was tuned
    against. The resulting script, if real, is actually executed against the
    current repository state; a non-zero real exit code force-overrides the
    verdict to FAIL in code (user-confirmed hard gate: the script is not up
    for LLM debate on a failure, only on a pass can subjective judgment add
    INCONCLUSIVE/risk notes).
    
    schema.py: artifact.artifact_type's CHECK constraint gains the 5 new
    types, plus migrate_expand_artifact_types() -- SQLite has no ALTER-based
    constraint migration, so this is the standard rebuild-copy-swap dance,
    applied for real to the live ~/.graphlemon/graphlemon.db (42 rows,
    verified byte-identical count before/after, integrity_check clean).
    
    skills/qa-task-validation.md and skills/project-sdd-planning.md already
    gained a standing principle from this same incident: verify cross-task
    data dependencies against real system state, not seeded fixtures alone
    (see prior commit d7035fc) -- this commit is the mechanism-level half of
    the same fix, not just the prose-guidance half.
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    bboonnee authored
     
    Browse File »

  • Adds the two Deploy Supervisor entities from 01-M §1.15/§1.16 (17 tables
    total): deployment (full 15-value blue-green state machine, per 01-M's own
    text rather than supervisor-auto-rollback-design.md §3's abbreviated
    summary table) and deploy_health_signal (append-only health/monitoring
    samples). ux_deployment_active enforces 01-M's "only one non-terminal
    deployment at a time" constraint via an expression-based unique index
    (CREATE UNIQUE INDEX ... ON deployment((1)) WHERE status NOT IN (...)) --
    the same partial-unique-index idiom work_graph_run already uses, just with
    a constant instead of a real grouping column since there's exactly one
    graphlemon self-target.
    
    bug_record.root_cause_category's schema-level CHECK now accepts
    core_engine, but bug_record.py's own application-layer whitelist
    deliberately does not follow yet -- classifying a bug as core_engine is a
    file-path-based rule (05 §5.8), not something the Validator's existing
    3-perspective judge_root_cause can produce, and wiring that classification
    + c_org_loop_route's routing is U-035's job.
    
    392 tests green.
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    bboonnee authored
     
    Browse File »

  • Implements docs/sdd/01-M-模型设计.md §1.0-1.14 as stdlib sqlite3 DDL in src/
    (deployment/deploy_health_signal §1.15-1.16 are PH5/U-034, deliberately
    excluded). Covers all entities' fields, enum CHECK constraints, FKs, and
    the two non-trivial unique indexes (work_graph_run's per-(task_id,org_node)
    active-run partial index, artifact's (task_id,artifact_type,git_commit_sha)
    composite key).
    
    Per user decision (2026-07-30): bug_record.root_cause_category excludes
    'core_engine' for now -- that value is PH5-scoped and development-plan.md
    assigns adding it to U-034, not U-001; a test locks this in.
    
    14 stdlib unittest cases in src/test_schema.py cover table creation and the
    Done criterion's named constraint classes (unique/FK/enum), all passing.
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    bboonnee authored
     
    Browse File »