Skip to content

(wip) docs(optimizer): CLAUDE.md + architecture doc with diagrams#605

Draft
mkuchenbecker wants to merge 2 commits into
mainfrom
mkuchenb/claude
Draft

(wip) docs(optimizer): CLAUDE.md + architecture doc with diagrams#605
mkuchenbecker wants to merge 2 commits into
mainfrom
mkuchenb/claude

Conversation

@mkuchenbecker
Copy link
Copy Markdown
Collaborator

Summary

Two files for the optimizer subsystem, both self-contained under services/optimizer/:

  • services/optimizer/CLAUDE.md — internal conventions for contributors / future Claude sessions working in services/optimizer/ or apps/optimizer/. Covers the library/deployable split, package convention, the concurrent-instance contract on table_operations, the pagination caveat, property naming, REST error contract, the Optional<T> repository pattern, and the H2-vs-MySQL gotchas. ~260 lines.

  • services/optimizer/ARCHITECTURE.md — externally-facing architecture overview: what it is, components, one cycle end-to-end, operation states, REST endpoints, opt-in, and adding a new operation type. ~80 lines. Backed by three PlantUML diagrams.

Diagrams

services/optimizer/diagrams/:

File Shows
components.puml + .png Analyzer, scheduler, optimizer service, optimizer DB; boundaries to tables service, jobs service, Spark job
sequence.puml + .png Five phases of one cycle: stats commit → analyzer → scheduler → job submit → per-table callbacks + history
state.puml + .png PENDING → SCHEDULING → SCHEDULED → history; CANCELED exit from PENDING

GitHub renders the committed PNGs inline in the markdown. PlantUML sources stay in the same directory; diagrams/render.sh carries the regeneration instructions (install PlantUML; run ./render.sh).

What's distilled out

Per direction, the diagrams describe data flow at the principle level — not retry, dedup, claim-then-verify, or other internal implementation details. The internal contract details (concurrent-instance dedup, pagination caveat, etc.) live in CLAUDE.md for contributors, not in the architecture doc for external readers.

Verification

  • Diagrams were cross-checked against the optimizer implementation on the live stack to keep component names, the operation-type registration shape, and the state transitions accurate.
  • ./services/optimizer/diagrams/render.sh reproduces the committed PNGs from source.

🤖 Generated with Claude Code

mkuchenbecker and others added 2 commits May 27, 2026 12:10
services/optimizer/ARCHITECTURE.md  — externally-facing description of
the optimizer subsystem: what it is, components, one cycle end-to-end,
operation states, REST endpoints, how to enable on a table, how to add
a new operation type.

services/optimizer/diagrams/        — diagram sources + rendered PNGs:
  components.puml + .png  — analyzer / scheduler / optimizer service /
                            optimizer DB; boundaries to tables service,
                            jobs service, and the Spark job
  sequence.puml   + .png  — five phases: stats commit, analyzer cycle,
                            scheduler cycle, job submission, callback +
                            history append
  state.puml      + .png  — PENDING → SCHEDULING → SCHEDULED → history;
                            CANCELED exit from PENDING
  render.sh               — PlantUML rendering instructions + one-shot
                            regeneration script

Distilled to the data-flow principles; retry, dedup specifics, and
internal implementation details are out of scope.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant