Project kickoff — 2026-09-17
Format: Zoom call (recorded; recording stopped at the end of the call). Participants: the project owner (repository maintainer) and the engineer being onboarded as repository admin and primary implementer, referred to below simply as “the engineer.”
Executive summary
The owner walked the engineer through the MetalDesk repository and granted them admin access. The
central process decision for the project: all code is written by Claude Code, not by hand — the
engineer directs Claude Code with instructions and reviews its output; they do not author
implementation code themselves. Legacy per-client repositories (the prior Dealboard delivery, e.g.
dealboard-api, dealboard-ui) may be added to Claude Code’s context with claude --add-dir so it
can see how a similar system was implemented, strictly as behavioral/requirements reference —
never to copy code, data, or configuration, since that IP belongs to the original client under the
delivery contract. This reaffirms the provenance boundary already stated in the
README: MetalDesk re-implements requirements
from scratch and contains nothing owned by that client.
The owner walked through the first three Modernization Plan phases —
monorepo/build-graph initialization, domain model and libraries (PaymentProvider, WireMock-backed
adapters), and the services layer — and asked the engineer to either confirm the plan as workable or
propose changes before implementation starts. Work proceeds phase by phase, one pull request per
phase, reviewed with Claude Code before merge.
Decisions
- Claude-Code-only development. No hand-written implementation code on this project; Claude Code executes all changes from instructions the engineer gives it.
- Legacy repos are reference-only. The Dealboard repositories the engineer has access to may be
loaded into Claude Code’s context via
claude --add-dirto inform requirements and behavior, never to be copied from. MetalDesk re-implements the business requirements independently — see the README provenance note and the Modernization Plan’s supersession note. - One PR per Modernization Plan phase, each reviewed with Claude Code before merge — consistent with CONTRIBUTING.md’s existing “one reviewer approval and a green CI run before merge” rule; this meeting adds that the review step itself is Claude-Code-assisted.
- Phase breakdown under discussion. The owner presented Modernization Plan Phases 1–3 (build
graph, domain model/libs, services) and asked the engineer to confirm this split or propose an
alternative before starting. Tooling called out by name during the walkthrough — WireMock for
mocking external dependencies, ArchUnit for architecture tests (e.g., no domain type used outside
libs/share, no controller reaching the database directly) — is already captured in ADR-0002 and ADR-0001 respectively; no new decision was made here, the meeting confirmed alignment with what’s already written.
Action items
| # | Action | Owner | Status |
|---|---|---|---|
| 1 | Confirm the Modernization Plan Phase 1–3 breakdown, or propose changes, before implementation starts | Engineer | Open |
| 2 | Start Phase 1 (monorepo/build graph) once the phase breakdown is confirmed; open it as a single PR | Engineer, via Claude Code | Open |
| 3 | Review each phase’s PR with Claude Code before merge | Engineer | Open — recurring, one per phase |
| 4 | Add the legacy Dealboard repositories via claude --add-dir only when a phase needs behavioral reference; never copy from them |
Engineer | Open — as-needed |
| 5 | Record this kickoff’s decisions in project documentation | Engineer, via Claude Code | Done — this page, plus the CONTRIBUTING.md workflow update it links to |
Open question
The phase breakdown (action item 1) was not confirmed on the call — the owner asked the engineer to either sign off on Phases 1–3 as documented or propose a different split. That confirmation is the gating step before any implementation PR is opened.
See also: Modernization Plan · CONTRIBUTING.md · ADRs