[#777] implement-workflow-builder#780
Open
nrslib wants to merge 2 commits into
Open
Conversation
📝 WalkthroughWalkthroughPR ChangesWorkflow Builder Feature
Estimated code review effort: 🎯 4 (Complex) | ⏱️ ~60 minutes ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/features/interactive/conversationLoop.ts (1)
242-257:⚠️ Potential issue | 🟡 Minor | ⚡ Quick win
/accept・/playの拒否メッセージを i18n 化してください。ここだけ固定英語文字列なので、
jaロケールでも英語表示になります。既存どおりinteractive.uiのラベル経由に揃えた方がよいです。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/features/interactive/conversationLoop.ts` around lines 242 - 257, Replace the hardcoded English refusal message inside the blocks that check strategy.disableDirectExecuteCommands (both where SlashCommand.Accept and SlashCommand.Play are handled) with an i18n lookup via the existing interactive.ui labels instead of the literal 'Use /go to apply confirmed changes.'; call the same ui label used elsewhere (e.g., ui.useGoToApply or add that key under interactive.ui/locales if missing) and pass the result to info() so the message is localized across locales.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/features/interactive/conversationLoop.ts`:
- Around line 364-366: The code displays the wrong message when resume is
disabled: in the branch checking strategy.enableResumeCommand === false it
currently calls ui.retryUnavailable; change that call to ui.resumeUnavailable
(or add that i18n string if missing) so the user sees a resume-specific message;
update any tests or callers referencing ui.retryUnavailable in this branch to
use ui.resumeUnavailable and keep the continue behavior in the conversationLoop
control flow.
In `@src/features/workflowAuthoring/builder/approval.ts`:
- Around line 54-83: The current fallback to latestAssistantCandidatePaths when
the user says `yes`/`ok` causes implicit approvals; change the logic so that
when hasMentionedCandidate is false you only use latestAssistantCandidatePaths
if the prior assistant message was an explicit approval request (use
isApprovalRequestMessage(...) on the assistant message that produced
latestAssistantCandidatePaths); otherwise require explicit path mentions and
skip approval. Update the branch around approved = hasMentionedCandidate ?
mentioned : latestAssistantCandidatePaths to check isApprovalRequestMessage(...)
and call removeApprovedBuilderCandidatePaths / addApprovedBuilderCandidatePath
accordingly.
In `@src/features/workflowAuthoring/builder/command.ts`:
- Around line 91-99: selectRequiredOption currently throws when selectOption
returns no selection, which causes the whole builderWorkflowCommand to reject on
simple user cancel; change selectRequiredOption to stop throwing and instead
return a nullable result (e.g., Promise<T | undefined>) when no selection is
made, so callers can handle an early return/abort gracefully; update the
selectRequiredOption signature and body to return undefined on cancel and then
update callers such as builderWorkflowCommand to check for falsy/undefined and
return early instead of relying on exceptions.
- Around line 132-141: When parseBuilderManifestForGo(...) returns falsy or
findBuilderChangeViolation(...) returns a plannedViolation, append the
validation feedback into goContext.history (same approach as in workflow
doctor/apply) instead of only logging to the terminal: call
buildBuilderValidationFeedback(...) with the appropriate inputs (e.g.,
options.scope, manifest or manifestChanges, and the error/violation message) and
push the result onto goContext.history before returning null; apply the same
change for the other block referenced around the 213-225 range so both
manifest-parse failures and approval-scope violations record feedback in
history.
In `@src/features/workflowAuthoring/builder/files.ts`:
- Around line 18-26: listFilesRecursive currently calls readdirSync on rootDir
even when rootDir is a regular file; add a directory check like the existing
symlink guard to return [] when lstatSync(rootDir).isDirectory() is false. In
other words, in function listFilesRecursive, after existsSync(rootDir) and
before calling readdirSync(rootDir), call lstatSync(rootDir) and if
!isDirectory() return []; this mirrors the symlink exclusion and prevents
ENOTDIR errors from readdirSync.
In `@src/features/workflowAuthoring/builder/manifest.ts`:
- Line 21: 現在の BUILDER_MANIFEST_JSON_BLOCK が最初のコードフェンス（json 指定なし）もマッチしてしまい説明用の
```yaml などで JSON.parse が失敗するので、まず ```json
を優先して抽出し、未指定フェンスはレスポンス全体が単一フェンスだった場合のみ許可するように修正してください: 定数を
BUILDER_MANIFEST_JSON_BLOCK = /```json\s*([\s\S]*?)```/i とし、別で
BUILDER_MANIFEST_SINGLE_FENCE = /^\s*```(?:json)?\s*([\s\S]*?)```\s*$/i
を定義、extractBuilderManifestJson(content: string) 内でまず BUILDER_MANIFEST_JSON_BLOCK
を試し、マッチしなければ BUILDER_MANIFEST_SINGLE_FENCE を試してマッチ時はそのグループを返し（trim
する）、どちらにもマッチしなければ元の content.trim() を返すようにしてください（関数名 extractBuilderManifestJson
と定数名を参照）。
In `@src/features/workflowAuthoring/builder/promptContext.ts`:
- Around line 71-88: The current buildScopeRelatedGraph function (and related
logic used at lines ~165-193) inlines full workflow and facet bodies for every
candidate, causing quadratic token growth; change buildScopeRelatedGraph to only
emit per-candidate metadata (path, relation, reason) by replacing/adjusting the
use of formatRelatedCandidates (or creating a new formatter) so it returns only
"path / relation / reason" entries, leaving out workflow/facet text, and ensure
buildRelatedWorkflowAnalysis consumers still provide candidate identifiers so
the actual bodies can be retrieved later on explicit "Read" requests during the
conversation.
- Around line 42-48: The buildBuilderSystemPrompt is injecting the Japanese
style guide because loadStyleGuide() (and similarly loadYamlSchema()) currently
always reads getLanguageResourcesDir('ja'); update buildBuilderSystemPrompt to
pass the lang through to the resource loaders so they load the matching language
(e.g., change calls to loadStyleGuide(lang) and loadYamlSchema(lang) or modify
those helpers to accept a language parameter), and apply the same change to the
other builder functions in the file (the block around lines 108-126) so English
prompts receive English resources and Japanese prompts receive Japanese
resources.
In `@src/features/workflowAuthoring/builder/validation.ts`:
- Around line 31-38: The loop over listBuilderTargetWorkflows currently calls
WorkflowConfigRawSchema.parse(parseYamlContent(workflow.path)) directly which
throws on any unreadable/invalid YAML and aborts facet-change resolution; wrap
the parse step in a try/catch (or reuse the same “skip unreadable workflow”
logic used by parseWorkflowForApprovalScope) so that if parseYamlContent or
WorkflowConfigRawSchema.parse fails you log or warn and continue to the next
workflow, then only call resolveUsedFacetPaths and potentially add
resolve(workflow.path) to targets for successfully parsed workflows.
---
Outside diff comments:
In `@src/features/interactive/conversationLoop.ts`:
- Around line 242-257: Replace the hardcoded English refusal message inside the
blocks that check strategy.disableDirectExecuteCommands (both where
SlashCommand.Accept and SlashCommand.Play are handled) with an i18n lookup via
the existing interactive.ui labels instead of the literal 'Use /go to apply
confirmed changes.'; call the same ui label used elsewhere (e.g.,
ui.useGoToApply or add that key under interactive.ui/locales if missing) and
pass the result to info() so the message is localized across locales.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: d6d613d2-19eb-4794-91df-0ae90bd4510a
📒 Files selected for processing (26)
e2e/specs/cli-workflow-authoring.e2e.tssrc/__tests__/commands-workflow.test.tssrc/__tests__/conversationLoop-builder-go.test.tssrc/__tests__/prompts.test.tssrc/__tests__/slashCommandRegistry.test.tssrc/__tests__/workflow-builder-command.test.tssrc/__tests__/workflow-builder.test.tssrc/app/cli/commands.tssrc/features/interactive/conversationLoop.tssrc/features/interactive/slashCommandRegistry.tssrc/features/workflowAuthoring/builder.tssrc/features/workflowAuthoring/builder/approval.tssrc/features/workflowAuthoring/builder/command.tssrc/features/workflowAuthoring/builder/constants.tssrc/features/workflowAuthoring/builder/files.tssrc/features/workflowAuthoring/builder/manifest.tssrc/features/workflowAuthoring/builder/promptContext.tssrc/features/workflowAuthoring/builder/scope.tssrc/features/workflowAuthoring/builder/snapshot.tssrc/features/workflowAuthoring/builder/types.tssrc/features/workflowAuthoring/builder/validation.tssrc/features/workflowAuthoring/builder/workflowGraph.tssrc/features/workflowAuthoring/index.tssrc/infra/config/loaders/workflowDoctorRefValidator.tssrc/shared/prompts/en/builder_system_prompt.mdsrc/shared/prompts/ja/builder_system_prompt.md
Owner
Author
Summaryタスク指示書: PR #780 のレビューコメント対応と修正タスク概要PR #780（ 対象
優先度: 高
|
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
src/features/workflowAuthoring/builder/command.ts (1)
89-92:⚠️ Potential issue | 🟠 Major | ⚡ Quick win空のスコープで
modifyを選ぶと、通常操作なのにコマンド全体が例外終了します。ここだけ
throwのままなので、ワークフロー未作成のプロジェクトで誤って「Modify」を選ぶとbuilderWorkflowCommand()が reject します。キャンセル時と同じく、案内して早期 return に寄せないと対話型 CLI の中断経路が不安定です。修正案
const workflows = listBuilderTargetWorkflows(scope); if (workflows.length === 0) { - throw new Error('No workflow files found in the selected scope.'); + info('No workflow files found in the selected scope.'); + return undefined; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/features/workflowAuthoring/builder/command.ts` around lines 89 - 92, The code currently throws when listBuilderTargetWorkflows(scope) returns an empty array, causing builderWorkflowCommand() to reject; change this behavior to mirror the user-cancel path: detect workflows.length === 0, print an informative message to the user (or use the existing CLI logger), and return early from builderWorkflowCommand instead of throwing so the interactive flow continues gracefully. Update the conditional around listBuilderTargetWorkflows(scope) to avoid throwing and ensure any callers expect a normal return rather than an exception.src/features/workflowAuthoring/builder/approval.ts (1)
67-89:⚠️ Potential issue | 🟠 Major | ⚡ Quick win混在した承認/拒否を 1 セグメントで送ると、言及した候補を全部外してしまいます。
isExplicitRejectionLine()に先に入るので、edit workflows/a.yaml but don't edit workflows/b.yamlのような文でもmentioned全体が rejected 扱いになり、Line 85 のパス単位除外まで到達しません。これだと関連編集の一部だけ承認する返答を正しく表現できません。💡 修正イメージ
+ const normalizedSegment = segment.trim().toLowerCase(); + const hasMentionedCandidate = mentioned.size > 0; - if (isExplicitRejectionLine(segment.trim().toLowerCase())) { + if (isExplicitRejectionLine(normalizedSegment) && !isExplicitApprovalLine(segment, hasMentionedCandidate)) { const rejected = mentioned.size > 0 ? mentioned : latestAssistantAskedForApproval ? latestAssistantCandidatePaths : new Set<string>(); removeApprovedBuilderCandidatePaths(scope, candidates, approvedWorkflowPaths, approvedFacetPaths, rejected); continue; } - const hasMentionedCandidate = mentioned.size > 0; if (!isExplicitApprovalLine(segment, hasMentionedCandidate)) { continue; }Based on learnings: 「AI生成コードの認証・認可ロジックを厳しく審査し、エッジケースの見落としを検出する」。
Also applies to: 220-236
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/features/workflowAuthoring/builder/approval.ts` around lines 67 - 89, The current logic treats any segment flagged by isExplicitRejectionLine(...) as rejecting the entire mentioned set, causing mixed "approve X but reject Y" segments like "edit workflows/a.yaml but don't edit workflows/b.yaml" to incorrectly remove all mentioned candidates; instead, change the flow to decide approval/rejection per candidate: do not call removeApprovedBuilderCandidatePaths(...) with the whole mentioned set up-front; iterate mentioned candidates (or iterate candidates and check membership in mentioned) and for each candidate call pathIsRejectedInText(scope, candidate.filePath, segment, candidates.map(...)) to determine rejection and otherwise check isExplicitApprovalLine(...) (or use isExplicitRejectionLine(...) scoped to the candidate) and call removeApprovedBuilderCandidatePath(...) or addApprovedBuilderCandidatePath(...) accordingly; alternately swap the guards so per-candidate rejection is determined after per-candidate approval checks rather than blanket-rejecting the entire mentioned set.src/features/workflowAuthoring/builder/workflowGraph.ts (1)
44-49:⚠️ Potential issue | 🟠 Major | ⚡ Quick win壊れた sibling workflow 1 件で関連グラフ全体が落ちます。
ここは候補走査中の各 workflow を
loadRawWorkflow()で無条件に読み込んでいるので、無関係な 1 ファイルでも YAML/Schema エラーがあるとbuildRelatedWorkflowAnalysis()自体が例外で終了します。src/features/workflowAuthoring/builder/promptContext.tsの Line 71-88 ではこれをスコープ内の全 workflow に対して呼ぶため、create/unspecifiedモードでも builder の prompt 構築全体が失敗します。sibling 側の parse failure は診断に落として skip しないと、既存の壊れた workflow があるだけで builder を起動できません。💡 最小修正案
for (const workflow of listBuilderTargetWorkflows(options.scope)) { if (resolve(workflow.path) === resolve(options.targetWorkflowPath)) { continue; } - const raw = loadRawWorkflow(workflow.path); + let raw: RawWorkflow; + try { + raw = loadRawWorkflow(workflow.path); + } catch (error) { + diagnostics.push( + `Skipped related workflow analysis for ${formatBuilderWorkflowPath(options.scope, workflow.path)}.`, + ); + continue; + } const workflowFacets = resolveUsedFacetPaths(options.scope, raw, workflow.path);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/features/workflowAuthoring/builder/workflowGraph.ts` around lines 44 - 49, The loop that iterates listBuilderTargetWorkflows unconditionally calls loadRawWorkflow (and then resolveUsedFacetPaths) so a YAML/schema parse error in any sibling workflow throws and aborts buildRelatedWorkflowAnalysis; wrap the per-workflow load/resolve in a try/catch, on error push a diagnostic/validation error for that workflow (so callers like the prompt builder see the failure) and continue to the next workflow instead of rethrowing—adjust the block around loadRawWorkflow and resolveUsedFacetPaths in buildRelatedWorkflowAnalysis (and code paths used by promptContext) to catch parse/validation errors, record them, and skip that workflow.builtins/en/skill/references/yaml-schema.md (1)
1-169:⚠️ Potential issue | 🟠 Major | ⚡ Quick win英語版の YAML schema 参照が日本語版より大幅に欠けています。
buildBuilderSystemPrompt('en', ...)はこのファイルをそのまま英語 builder の schema source として注入しますが、現状はbuiltins/ja/skill/references/yaml-schema.mdにあるoutput_contracts/quality_gates/ テンプレート変数 / 詳細なloop_monitors/allowed_toolsの説明が英語版にありません。これだと locale ごとに builder が受け取る制約が変わってしまい、英語側だけ不完全な YAML を提案しやすくなります。少なくとも日本語版と同じ契約面は揃えておいた方が安全です。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@builtins/en/skill/references/yaml-schema.md` around lines 1 - 169, The English YAML schema (used by buildBuilderSystemPrompt('en', ...)) is missing several contract fields present in the Japanese schema (output_contracts, quality_gates, template variables, detailed loop_monitors, allowed_tools), which causes inconsistent builder constraints per locale; update the English schema document (yaml-schema.md) to mirror the Japanese version by adding the missing sections and their detailed descriptions (output_contracts, quality_gates, template/template-variable usage, loop_monitors examples, allowed_tools semantics and examples) so the builder injected by buildBuilderSystemPrompt('en', ...) receives the same contract surface as the Japanese schema and ensure any validation or generation logic that reads those keys remains compatible.
♻️ Duplicate comments (2)
src/features/workflowAuthoring/builder/manifest.ts (1)
21-22:⚠️ Potential issue | 🟠 Major | ⚡ Quick win単一の bare code fence が同一行だと、まだ manifest を取り出せません。
SINGLE_UNTYPED_CODE_BLOCKが改行必須なので、LLM がレスポンス全体を ```````{"summary":"...","changes":[]}````` のような 1 行 fence で返すと unwrap されず、そのままJSON.parse()が失敗します。レスポンス全体が単一 fence のときは、改行の有無に関係なく剥がした方が安全です。💡 修正イメージ
-const SINGLE_UNTYPED_CODE_BLOCK = /^```\s*\r?\n([\s\S]*?)```$/; +const SINGLE_UNTYPED_CODE_BLOCK = /^```\s*([\s\S]*?)```$/;Based on learnings: 「AI生成コードの入力バリデーションを厳しく審査し、構文検証だけでなく意味的バリデーションを確認する」。
Also applies to: 75-82
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/features/workflowAuthoring/builder/manifest.ts` around lines 21 - 22, SINGLE_UNTYPED_CODE_BLOCK currently requires a newline after the opening ``` so one-line bare fences like ```{"summary":"...","changes":[]}``` aren't unwrapped and later JSON.parse fails; update the regex for SINGLE_UNTYPED_CODE_BLOCK (and the duplicate occurrence around the 75-82 region) to allow optional whitespace/newline after the opening fence (i.e., change from /^```\\s*\\r?\\n([\\s\\S]*?)```$/ to a pattern that does not mandate the newline, e.g., /^```\\s*([\\s\\S]*?)```$/) so single-line fenced JSON is correctly captured before parsing.src/features/workflowAuthoring/builder/validation.ts (1)
224-235:⚠️ Potential issue | 🟠 Major | ⚡ Quick winread 失敗はまだ skip されていません。
この helper は YAML/Schema の失敗を
undefinedに落とせていますが、Line 225 のreadFileSync()はその前に throw します。権限エラーや壊れた symlink が 1 件あるだけで、resolveBuilderValidationTargets()とcollectFacetPathsReferencedByUnapprovedWorkflows()が再び全体中断になります。read 失敗もここで明示的に skip 扱いにしてください。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/features/workflowAuthoring/builder/validation.ts` around lines 224 - 235, The helper parseWorkflowForApprovalScope currently calls readFileSync(workflowPath) which can throw and abort higher-level flows like resolveBuilderValidationTargets and collectFacetPathsReferencedByUnapprovedWorkflows; wrap the file read in a try/catch so any IO errors (permission, broken symlink, etc.) cause the function to return undefined (skip) instead of throwing, then proceed with parseDocument, convertYamlDocumentForApprovalScope, and WorkflowConfigRawSchema.safeParse as before; ensure you reference parseWorkflowForApprovalScope and readFileSync to locate the change and keep the existing return shape (undefined on any failure).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/features/workflowAuthoring/builder/command.ts`:
- Line 47: Replace hard-coded English UI strings in command.ts with i18n keys:
add the new keys for the wizard labels/progress/failure messages to the YAML
files under src/shared/i18n/* and ensure they are included in the dist build,
then load a translator using ctx.lang and use it where the strings are currently
passed to selectRequiredOption, in the wizard prompts and progress/failure
messages (the same area that calls buildBuilderSystemPrompt(ctx.lang, ...)),
replacing the literal strings referenced around selectRequiredOption and the
following wizard/display calls with translator(key) lookups so the UI follows
ctx.lang.
---
Outside diff comments:
In `@builtins/en/skill/references/yaml-schema.md`:
- Around line 1-169: The English YAML schema (used by
buildBuilderSystemPrompt('en', ...)) is missing several contract fields present
in the Japanese schema (output_contracts, quality_gates, template variables,
detailed loop_monitors, allowed_tools), which causes inconsistent builder
constraints per locale; update the English schema document (yaml-schema.md) to
mirror the Japanese version by adding the missing sections and their detailed
descriptions (output_contracts, quality_gates, template/template-variable usage,
loop_monitors examples, allowed_tools semantics and examples) so the builder
injected by buildBuilderSystemPrompt('en', ...) receives the same contract
surface as the Japanese schema and ensure any validation or generation logic
that reads those keys remains compatible.
In `@src/features/workflowAuthoring/builder/approval.ts`:
- Around line 67-89: The current logic treats any segment flagged by
isExplicitRejectionLine(...) as rejecting the entire mentioned set, causing
mixed "approve X but reject Y" segments like "edit workflows/a.yaml but don't
edit workflows/b.yaml" to incorrectly remove all mentioned candidates; instead,
change the flow to decide approval/rejection per candidate: do not call
removeApprovedBuilderCandidatePaths(...) with the whole mentioned set up-front;
iterate mentioned candidates (or iterate candidates and check membership in
mentioned) and for each candidate call pathIsRejectedInText(scope,
candidate.filePath, segment, candidates.map(...)) to determine rejection and
otherwise check isExplicitApprovalLine(...) (or use isExplicitRejectionLine(...)
scoped to the candidate) and call removeApprovedBuilderCandidatePath(...) or
addApprovedBuilderCandidatePath(...) accordingly; alternately swap the guards so
per-candidate rejection is determined after per-candidate approval checks rather
than blanket-rejecting the entire mentioned set.
In `@src/features/workflowAuthoring/builder/command.ts`:
- Around line 89-92: The code currently throws when
listBuilderTargetWorkflows(scope) returns an empty array, causing
builderWorkflowCommand() to reject; change this behavior to mirror the
user-cancel path: detect workflows.length === 0, print an informative message to
the user (or use the existing CLI logger), and return early from
builderWorkflowCommand instead of throwing so the interactive flow continues
gracefully. Update the conditional around listBuilderTargetWorkflows(scope) to
avoid throwing and ensure any callers expect a normal return rather than an
exception.
In `@src/features/workflowAuthoring/builder/workflowGraph.ts`:
- Around line 44-49: The loop that iterates listBuilderTargetWorkflows
unconditionally calls loadRawWorkflow (and then resolveUsedFacetPaths) so a
YAML/schema parse error in any sibling workflow throws and aborts
buildRelatedWorkflowAnalysis; wrap the per-workflow load/resolve in a try/catch,
on error push a diagnostic/validation error for that workflow (so callers like
the prompt builder see the failure) and continue to the next workflow instead of
rethrowing—adjust the block around loadRawWorkflow and resolveUsedFacetPaths in
buildRelatedWorkflowAnalysis (and code paths used by promptContext) to catch
parse/validation errors, record them, and skip that workflow.
---
Duplicate comments:
In `@src/features/workflowAuthoring/builder/manifest.ts`:
- Around line 21-22: SINGLE_UNTYPED_CODE_BLOCK currently requires a newline
after the opening ``` so one-line bare fences like
```{"summary":"...","changes":[]}``` aren't unwrapped and later JSON.parse
fails; update the regex for SINGLE_UNTYPED_CODE_BLOCK (and the duplicate
occurrence around the 75-82 region) to allow optional whitespace/newline after
the opening fence (i.e., change from /^```\\s*\\r?\\n([\\s\\S]*?)```$/ to a
pattern that does not mandate the newline, e.g., /^```\\s*([\\s\\S]*?)```$/) so
single-line fenced JSON is correctly captured before parsing.
In `@src/features/workflowAuthoring/builder/validation.ts`:
- Around line 224-235: The helper parseWorkflowForApprovalScope currently calls
readFileSync(workflowPath) which can throw and abort higher-level flows like
resolveBuilderValidationTargets and
collectFacetPathsReferencedByUnapprovedWorkflows; wrap the file read in a
try/catch so any IO errors (permission, broken symlink, etc.) cause the function
to return undefined (skip) instead of throwing, then proceed with parseDocument,
convertYamlDocumentForApprovalScope, and WorkflowConfigRawSchema.safeParse as
before; ensure you reference parseWorkflowForApprovalScope and readFileSync to
locate the change and keep the existing return shape (undefined on any failure).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 38b5e8ad-5bd3-425a-a03b-4d84b42015e6
📒 Files selected for processing (18)
builtins/en/skill/references/yaml-schema.mdbuiltins/ja/skill/references/yaml-schema.mdsrc/__tests__/conversationLoop-builder-go.test.tssrc/__tests__/workflow-builder-command.test.tssrc/__tests__/workflow-builder.test.tssrc/features/interactive/conversationLoop.tssrc/features/interactive/interactive.tssrc/features/workflowAuthoring/builder/approval.tssrc/features/workflowAuthoring/builder/command.tssrc/features/workflowAuthoring/builder/constants.tssrc/features/workflowAuthoring/builder/files.tssrc/features/workflowAuthoring/builder/manifest.tssrc/features/workflowAuthoring/builder/promptContext.tssrc/features/workflowAuthoring/builder/types.tssrc/features/workflowAuthoring/builder/validation.tssrc/features/workflowAuthoring/builder/workflowGraph.tssrc/shared/i18n/labels_en.yamlsrc/shared/i18n/labels_ja.yaml
💤 Files with no reviewable changes (1)
- src/features/workflowAuthoring/builder/types.ts
| const ctx = initializeSession(options.projectDir, 'workflow-builder'); | ||
| displayAndClearSessionState(options.projectDir, ctx.lang); | ||
|
|
||
| const scopeKind = await selectRequiredOption('Select output scope:', buildBuilderScopeChoices(options.projectDir)); |
There was a problem hiding this comment.
ビルダーの新規 UI 文言が i18n を通っていません。
ctx.lang で言語は解決できていて、system prompt も buildBuilderSystemPrompt(ctx.lang, ...) で分岐している一方、ウィザード文言・進捗表示・失敗案内は英語固定です。ja 環境ではこのコマンドだけ混在表示になるので、今回追加した表示文言はラベル化した方がよいです。As per coding guidelines, src/shared/i18n/*.yaml: Define internationalization strings in YAML under src/shared/i18n/; copy to dist/ during build.
Also applies to: 63-63, 77-80, 93-95, 124-124, 133-153, 172-172, 247-247, 275-275
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/features/workflowAuthoring/builder/command.ts` at line 47, Replace
hard-coded English UI strings in command.ts with i18n keys: add the new keys for
the wizard labels/progress/failure messages to the YAML files under
src/shared/i18n/* and ensure they are included in the dist build, then load a
translator using ctx.lang and use it where the strings are currently passed to
selectRequiredOption, in the wizard prompts and progress/failure messages (the
same area that calls buildBuilderSystemPrompt(ctx.lang, ...)), replacing the
literal strings referenced around selectRequiredOption and the following
wizard/display calls with translator(key) lookups so the UI follows ctx.lang.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
背景・動機
ワークフローを作るには、YAML スキーマとファセット分離（persona/policy/knowledge/instruction/output-contract）を理解した上で手書きする必要がある。
takt workflow initは静的雛形を出すだけで設計判断は人間任せ。takt-builderの知識（STYLE_GUIDE、yaml-schema、ファセット分離判断）を 対話する AI（builder） として常駐させ、要件を話すだけで設計・生成・検証できるようにする。workflow名前空間に、doctor（診断する人）と対になる役割名詞builder（組み立てる人）を追加する。コマンド
src/app/cli/commands.tsのworkflowサブコマンドにinit/doctorと並べて登録。設計の中心：ワークフロー中心、ファセットは選ばない
ユーザーはファセットを直接選ばない。エントリは常にワークフローで、「このワークフローでこういうことをしたい」という意図に合わせて builder がファセット（persona/policy/knowledge/instruction/output-contract）を生成・更新する。
基本方針：軽量ウィザード + 会話のハイブリッド
起動直後に 構造的な軸だけ を軽量ウィザード（対話の選択 UI、CLI フラグではない）で確定させ、そこから先は builder AI との自由対話に落とす。ただしターゲットを絞りたくない場合は、ウィザードを最小限にして即対話へ移れる。
フェーズ1：ウィザード（構造軸の確定）
出力先 scope
.takt/~/.takt/builtins/{en,ja}/（TAKT リポジトリ内でのみ表示。builtins/ja/STYLE_GUIDE.mdの存在で自動検出し、検出時のみ候補に出す）ターゲット
（「既存ワークフローを修正」のみ）対象ワークフロー選択
workflows/*.yamlをGlobで一覧表示し、対象を選ぶ。Glob/Readで探索しながら対話で対象を特定する。フェーズ2：会話（設計・生成）
ウィザードで確定した軸（または「絞らない」前提）で、builder AI と自由対話で中身を詰める。
/goで生成内容を確定、/cancelで破棄。関連ワークフロー・ファセットの波及編集（確認フロー）
ワークフローを1つ指定しても、builder はそれと 関連するファセットや類似ワークフローを探索 し、見つかれば 「これも編集しますか？」とユーザーに問いかけ、OK が出たものだけ編集 する。勝手に広げない。
workflow_call:で呼ぶサブワークフロー／対象を呼ぶ親ワークフローreview-*系）workflowDoctorRefValidator（ファセット参照・未使用検出）とworkflow_call契約検証の仕組みを利用して関連グラフを構築する。ユーザーディレクトリの理解
builder には対象 scope の既存資産を把握させる。
workflows/・facets/・config.yamlを読み、再利用可能な既存資産リストとワークフロー間の関連グラフを systemPrompt に注入（assistantInitFiles.ts/runSessionReader.tsと同じ流儀）。allowedToolsにRead/Glob/Grepを許可し、対話中に自分で深掘りできるようにする。builder の知識・指示はプロンプトテンプレートで持つ
builder の systemPrompt は ファセットではなくプロンプトテンプレート として実装する。
src/shared/prompts/{en,ja}/builder_system_prompt.md（仮）を新設し、loadTemplate('builder_system_prompt', lang, vars)で読む（perform_agent_system_prompt.mdなどと同じ仕組み）。yaml-schema（TAKT 本体builtins/{lang}/の Single Source of Truth）はテンプレート変数として注入し、重複を持たない。builtin（TAKT 開発者）モードの固有挙動
scope =
builtins/のときだけ en / ja の両言語を生成・同期 する。片方で作ってもう一方へミラー（翻訳）。project / global には無い分岐。生成と検証
/goで生成内容を確定 → ワークフロー YAML・関連ファセット・（OK の出た）波及先をWrite。inspectWorkflowFile()（workflow doctorの検証エンジン）を編集対象すべてに対して自動実行し、スキーマ・グラフ到達性・ファセット参照を検証。エラーは対話に差し戻して修正させる。実装スケッチ
src/features/interactive/conversationLoop.ts::runConversationLoop()を再利用。strategy（systemPrompt =loadTemplate('builder_system_prompt', ...)/ allowedTools / transformPrompt / introMessage）を builder 用に差し替える。workflowDoctorRefValidatorとworkflow_call契約検証を流用。aiCaller.ts::callAIWithRetry()、セッション初期化はsessionInitialization.tsを流用。/goフックを「ファイル生成 → Write → doctor 検証」に差し替え。commands.ts:スコープ外
takt runの役割）。受け入れ条件
takt workflow builderを引数・フラグなしで起動できる。src/shared/prompts/{en,ja}/のテンプレートとして実装され、STYLE_GUIDE /yaml-schemaを変数注入している。workflow doctorの検証を通る。Execution Report
Workflow
takt-defaultcompleted successfully.Closes #777
Summary by CodeRabbit
New Features
Documentation
Tests