Clarify runbook so devclaw-local-dev is the live pre-promotion validation lane before promotion into devclaw-local-current

[fujiwaranosai850]

Problem

The current local DevClaw runbook improved the branch-role split, but it still does not clearly represent the intended release/test sequence.

What the runbook currently makes clear:

• ordinary implementation starts from devclaw-local-dev
• issue work happens on issue/*
• developer completion normally lands into devclaw-local-dev
• promotion toward local truth then uses review/* into devclaw-local-current
• upstream export later uses pr/*

But it still leaves a critical sequencing rule under-specified:

the accepted implementation should first make devclaw-local-dev the live validation lane, and testing should happen there before promotion into devclaw-local-current.

Right now the runbook still reads too much like review/merge/testing are centered on devclaw-local-current, instead of making the lane distinction explicit:

• devclaw-local-dev = live development validation lane
• devclaw-local-current = accepted local-truth / promotion / deploy / local-doc lane

Intended workflow to represent clearly

1. issue/* branches from devclaw-local-dev
2. developer PR lands in devclaw-local-dev
3. devclaw-local-dev is made live for development validation/testing
4. after that passes, promotion package is applied onto review/* from devclaw-local-current
5. review/* merges into devclaw-local-current
6. later, upstreamable changes are applied onto pr/*
7. pr/* is used for the upstream PR handoff

Why this matters

Without this clarification, the runbook still leaves room for the wrong mental model:

• treating devclaw-local-current as the first live validation lane for ordinary implementation work
• blurring the difference between development validation and accepted local truth
• misreading Add live orchestrator intervention for in-flight worker execution #203-style work as complete once it is live on current, instead of understanding the intended progression through dev

Requested change

Update the local runbook on devclaw-local-current so it explicitly states:

• devclaw-local-dev is the ordinary implementation base branch and the live pre-promotion validation lane
• devclaw-local-current is the accepted local-truth / promotion lane
• the normal promotion path is:
  • issue/* -> devclaw-local-dev
  • live validation on devclaw-local-dev
  • review/* -> devclaw-local-current
  • pr/* -> upstream
• any examples, operating-model bullets, and promotion text should align with that sequence

Scope

This is intended as an orchestrator/local-doc implementation task, not a broad product behavior change.

Done when

• the local runbook explicitly describes devclaw-local-dev as the live development validation lane
• the promotion flow explicitly distinguishes validation on dev from accepted local truth on current
• the documented branch sequence matches the intended lane model without ambiguity

[fujiwaranosai850]

🎛️ ORCHESTRATOR: Handled directly as operator-side runbook work and landed on devclaw-local-current.

Commit:

• 15846cf docs: clarify dev live-validation lane (#210)

What changed:

• devclaw-local-dev is now explicitly described as both the ordinary implementation base branch and the live pre-promotion validation lane
• devclaw-local-current is now explicitly described as accepted local truth
• the operating model now says ordinary implementation should be validated live on devclaw-local-dev before promotion into devclaw-local-current
• the typical flow now explicitly distinguishes:
  • issue/* -> devclaw-local-dev
  • live validation on devclaw-local-dev
  • review/* -> devclaw-local-current
  • pr/* -> upstream
• the promotion responsibilities now explicitly include the devclaw-local-dev live-validation checkpoint when that lane requires it

This should remove the remaining ambiguity that still made devclaw-local-current sound like the first live validation lane for ordinary implementation work.