* fix(#2402): honor response_language across orchestrator output + UAT checkpoint renderer Replays the in-flight bot branch fix/2402-response-language-orchestrator-coverage (seven commits, never pushed) onto current origin/next as a single squashed commit. The original work was substantial and correct; this commit preserves its full scope, trimmed where rebase conflicts + workflow size budgets required it. Three independent layers where response_language was being dropped are closed: Layer 1 — orchestrator-facing directives across workflows. Adds the strong "All user-facing output in this workflow MUST be presented in {response_language}; technical terms, code, paths, and subagent prompts stay in English" directive to ~40 workflows that previously either lacked it entirely (verify-work, new-project, new-milestone, quick, manager, and ~35 more) or carried only the weak subagent-prompt-only form (plan-phase, execute-phase). The directive covers narration between tool calls and banner output, not just the AskUserQuestion prompts. Layer 2 — UAT checkpoint renderer (src/uat.cts). buildCheckpoint now accepts an optional responseLanguage parameter and renders the frame strings ("CHECKPOINT: Verification Required", "Type `pass` or describe what's wrong.") in any of 9 languages (English/Spanish/French/German/Portuguese/Japanese/ Chinese/Korean/Italian) with an alias table covering ~30 input variants (en, es, español, ja, 日本語, etc.). cmdRenderCheckpoint reads config.response_language via loadConfig(cwd) and passes it through, so the byte-for-byte block verify-work.md reprints verbatim is already localized when written — preserving the anti-injection hygiene rule at verify-work.md (the model is forbidden to translate after the fact). CJK display width is computed by East Asian Width property ranges (W/F) so the right ║ border of the banner stays aligned for full-width characters. English fallback is byte-identical to the pre-fix behavior when response_language is unset or unrecognized. Layer 3 — literal English report templates in execute-phase. The top-of- workflow directive covers all template sites (templates are a structural source, not literal output). Inline render-language notes that previously sat at each template site were removed during the squash because they pushed execute-phase.md over its frozen pre-phase-6 byte ceiling (93600 — ADR-857 Phase 6 capstone). The single top directive covers the same surface with fewer bytes. Also extends src/docs.cts and src/init.cts to propagate response_language into the init JSON bundle of the additional workflows so the directive can read it. Tests added: - tests/uat.test.cjs: buildCheckpoint with unset/unrecognized language falls back to English default; recognized language swaps only the two frame strings while structural lines stay untouched; CJK display-width regression (independent recomputation of East Asian Width W/F ranges). - tests/workspace.test.cjs, tests/docs-update.test.cjs: response_language wiring through docs.cts/init.cts. References: #2402; reporter's three-layer triage + Layer-4 follow-up; the byte-for-byte anti-injection hygiene rule at verify-work.md (the reason Layer 2 must be renderer-side, not model-translated). This is a squash of the in-flight bot branch — seven commits representing the original implementation plus its subsequent fix/CJK-padding/test/ changeset/regen cycles, none of which were ever pushed or PR'd. The squash captures the final coherent state. * chore(#2402): backfill pr:2457 in .changeset/2402-response-language-orchestrator-coverage.md * chore(#2402): regen golden + size baseline after rebase against #2315 (PR #2451) Rebase conflicts were entirely in generated artifacts (golden-install-parity fixtures + workflow-size-baseline.json). After taking theirs during rebase, regenerated cleanly against the merged source tree.
8.7 KiB
/gsd:onboard Workflow
One-command onboarding for an existing or unknown repo. This workflow is a thin
renderer around init onboard; deterministic routing lives in the CLI projection.
@~/.claude/gsd-core/references/gsd-run-resolver.md
1. Render the Onboarding Projection
Parse $ARGUMENTS:
--fastpasses--fasttoinit onboard. Fast mode accepts the fast map for lightweight onboarding only;next_actionstill decides whether complete map work is required before project setup.--textforces text-mode choices for runtimes withoutAskUserQuestion.
Run the standard gsd_run resolver from the reference above, then run the projection from the runtime root:
# If --fast was parsed from $ARGUMENTS:
INIT=$(gsd_run --cwd "$_GSD_RUNTIME_ROOT" init onboard --fast --raw)
# Otherwise:
INIT=$(gsd_run --cwd "$_GSD_RUNTIME_ROOT" init onboard --raw)
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
Parse JSON fields from INIT:
next_action.kind,next_action.command,next_action.reason,next_action.missing,next_action.summary_pathhandoff_commands.ingest_docs,handoff_commands.manager,handoff_commands.new_project,handoff_commands.onboardmap_readiness,codebase_map_summary_status,codebase_map_final_statusplanning_exists,project_exists,requirements_exists,roadmap_exists,state_existsis_brownfield,fast_mode,has_codebase_map,has_fast_codebase_mapmissing_codebase_map_files,missing_fast_codebase_map_fileshas_docs_candidates,doc_candidate_count,onboarding_summary_existscommit_docs,text_mode,has_git,git_worktree_root,in_nested_subdirresponse_language
If response_language is set: All user-facing questions, prompts, and explanations in this workflow MUST be presented in {response_language}. Technical terms, code, file paths, and subagent prompts stay in English — only user-facing output is translated.
Set:
TEXT_MODE=trueif--textis present ortext_modeis true. WhenTEXT_MODEis active, replace everyAskUserQuestioncall below with a plain-text numbered list and ask the user to type their choice number — required for non-Claude runtimes (OpenAI Codex, Gemini CLI, etc.) whereAskUserQuestionis not available.ONBOARDING_ROOT={git_worktree_root || _GSD_RUNTIME_ROOT}.
If has_git and in_nested_subdir are true, warn that onboarding artifacts belong to the outer worktree at git_worktree_root. Do not run git init.
2. Execute next_action
map-codebase
If next_action.kind == "map-codebase":
- If
TEXT_MODE=true, print:
{next_action.reason}
Missing map files: {fast_mode ? missing_fast_codebase_map_files : missing_codebase_map_files}
1. Map codebase first — run {next_action.command} from worktree root {ONBOARDING_ROOT} (Recommended)
2. Skip mapping — continue with weaker onboarding context
Enter number:
- Otherwise use AskUserQuestion:
- header: "Codebase"
- question: "{next_action.reason} Map it first?"
- options:
- "Map codebase first" — Run
{next_action.command}from worktree root{ONBOARDING_ROOT}(Recommended) - "Skip mapping" — Continue with weaker onboarding context
- "Map codebase first" — Run
If the user chooses mapping, do not nest the interactive workflow. Print:
Run from worktree root {ONBOARDING_ROOT}:
{next_action.command}
Then rerun {handoff_commands.onboard} from the same worktree root.
Exit. If the user skips mapping:
- If
(project_exists || requirements_exists || roadmap_exists || state_exists) && (!project_exists || !requirements_exists || !roadmap_exists || !state_exists), route the skip to the partial planning guard instead:
Skipping codebase mapping may give downstream steps weaker context, but project planning exists and is incomplete.
PROJECT.md: {project_exists ? "present" : "missing"}
REQUIREMENTS.md: {requirements_exists ? "present" : "missing"}
ROADMAP.md: {roadmap_exists ? "present" : "missing"}
STATE.md: {state_exists ? "present" : "missing"}
Run the appropriate lower-level command to fill the missing planning artifact(s), then rerun {handoff_commands.onboard}.
Exit.
- If
has_docs_candidates && !project_exists, route the skip to docs ingest instead:
Skipping codebase mapping may give downstream steps weaker context, but existing ADR/PRD/SPEC/RFC documents should still be ingested before {handoff_commands.new_project}.
Run from worktree root {ONBOARDING_ROOT}:
{handoff_commands.ingest_docs}
Then rerun {handoff_commands.onboard} from the same worktree root.
Exit.
- Otherwise print:
Skipping codebase mapping may give {handoff_commands.new_project} weaker context.
Run from worktree root {ONBOARDING_ROOT}:
{handoff_commands.new_project}
Then rerun {handoff_commands.onboard} from the same worktree root.
Exit.
ingest-docs
If next_action.kind == "ingest-docs":
- If
TEXT_MODE=true, print:
{next_action.reason}
Detected {doc_candidate_count} possible ADR/PRD/SPEC/RFC document(s).
1. Ingest docs first — run {next_action.command} from worktree root {ONBOARDING_ROOT} (Recommended)
2. Skip docs ingest — continue to {handoff_commands.new_project}
Enter number:
- Otherwise use AskUserQuestion:
- header: "Docs"
- question: "Detected {doc_candidate_count} possible ADR/PRD/SPEC/RFC document(s). Ingest them first?"
- options:
- "Ingest docs first" — Run
{next_action.command}from worktree root{ONBOARDING_ROOT}(Recommended) - "Skip docs ingest" — Continue to
{handoff_commands.new_project}
- "Ingest docs first" — Run
If the user chooses ingest, print:
Run from worktree root {ONBOARDING_ROOT}:
{next_action.command}
Then rerun {handoff_commands.onboard} from the same worktree root.
Exit. If the user skips docs ingest, print:
Skipping docs ingest may omit existing ADR/PRD/SPEC/RFC context from {handoff_commands.new_project}.
Run from worktree root {ONBOARDING_ROOT}:
{handoff_commands.new_project}
Then rerun {handoff_commands.onboard} from the same worktree root.
Exit.
complete-map-before-new-project
If next_action.kind == "complete-map-before-new-project", print:
{next_action.reason}
Run from worktree root {ONBOARDING_ROOT}:
{next_action.command}
Then rerun {handoff_commands.onboard} from the same worktree root.
Exit.
new-project
If next_action.kind == "new-project", print:
{next_action.reason}
Run from worktree root {ONBOARDING_ROOT}:
{next_action.command}
Then rerun {handoff_commands.onboard} from the same worktree root.
Exit.
partial-planning
If next_action.kind == "partial-planning", print:
Project planning exists but is incomplete.
Missing files: {next_action.missing}
REQUIREMENTS.md: {requirements_exists ? "present" : "missing"}
ROADMAP.md: {roadmap_exists ? "present" : "missing"}
STATE.md: {state_exists ? "present" : "missing"}
Run the appropriate lower-level command to fill the missing planning artifact(s), then rerun {handoff_commands.onboard}.
Exit.
ready
If next_action.kind == "ready", print the final status section and exit.
write-summary
If next_action.kind == "write-summary", continue to summary creation.
3. Create Onboarding Summary
Create {ONBOARDING_ROOT}/{next_action.summary_path}. Do not overwrite an existing summary; the projection should only route here when the summary is missing.
Summary template:
# Onboarding Summary
## Project State
- PROJECT.md: {project_exists ? "present" : "missing"}
- REQUIREMENTS.md: {requirements_exists ? "present" : "missing"}
- ROADMAP.md: {roadmap_exists ? "present" : "missing"}
- STATE.md: {state_exists ? "present" : "missing"}
## Codebase Context
- Brownfield repo: {is_brownfield ? "yes" : "no"}
- Map readiness: {map_readiness}
- Codebase map: {codebase_map_summary_status}
- Fast map available: {has_fast_codebase_map ? "yes" : "no"}
## Docs Context
- Existing ADR/PRD/SPEC/RFC candidates: {has_docs_candidates ? doc_candidate_count : 0}
## Recommended Next Step
- {handoff_commands.manager}
If commit_docs is true, commit only the summary path from the onboarding root:
gsd_run --cwd "$ONBOARDING_ROOT" query commit "docs: create onboarding summary" --files .planning/onboarding/SUMMARY.md
Continue to final status.
4. Final Status
Print:
Onboarding status:
- PROJECT.md: {project_exists ? "present" : "missing"}
- REQUIREMENTS.md: {requirements_exists ? "present" : "missing"}
- ROADMAP.md: {roadmap_exists ? "present" : "missing"}
- STATE.md: {state_exists ? "present" : "missing"}
- Codebase map: {codebase_map_final_status}
- Onboarding summary: present
Next recommended command: {handoff_commands.manager}
Do not run implementation execution or shipping from onboarding.