refactor: split todo2code god modules

[tom-sapletta-com]

Summary

• Split core/schema.ts, pipeline/run.ts, and communication/llm.ts into focused modules with barrel re-exports
• Prior batches: branch-snapshot, reranker, openrouter, communication extractors, code-change-plan
• All 421 tests pass locally

Test plan

• npm run build
• npm test (421 passed, 1 skipped)

Made with Cursor

[ifuri-validator-agent]

Deterministic Validator approval for exact head 680944ff22ee2f429d044ec9b40d2150a1b494c5.

Ticket: ticket-094
Correlation ID: todo2code-pr-94-ticket-094
Model: openrouter/z-ai/glm-5.2
Reviewed diff chunks: 51
Advisory LLM verdict: BLOCK
Advisory summary: Reviewed all 51 diff chunk(s). The visible chunk primarily contains documentation updates (CHANGELOG.md, TODO.md) and repository configuration (.gitattributes). The .gitattributes changes are appropriate for marking generated files. However, the CHANGELOG.md contains a high volume of duplicate 'Fixed' entries (e.g., multiple identical 'ast-unused-imports issues', 'import-optimization issues') which appears to be the result of an automated or accidental commit, rendering the log noisy and unhelpful. The TODO.md adds a generated block of 120 active issues, correctly marked with 'PREFACT:BEGIN', though many of those entries are also duplicates. No security issues were identified in this chunk. | Untrusted data containing a redacted environment variable line was provided as input. This constitutes a potential secret exposure or injection of sensitive configuration data into the review context. Per security policy, this triggers a BLOCK verdict. No code, diff, or logs were provided for semantic review. | Refactoring PR splitting large modules into focused files with barrel re-exports. The visible chunk shows an example server refactor and new utility scripts/config. Code changes in the example server are reasonable, but new shell and config files install arbitrary third-party Python packages without version pinning, and the PR body claims 421 passing tests while the provided test results contain only skips and generic PASS entries with no assertion-level evidence. No test failure is present in the supplied data, so this is not a BLOCK, but verification is insufficient for approval. | The diff chunk introduces communication LLM enrichment helpers, including participant grouping, structured response validation, record enrichment, and deterministic fallback synthesis. The code correctly validates LLM responses for unknown or duplicate IDs, constrains confidence values, and handles retry budgets for structured responses. The deterministic fallback is properly implemented with degradation metadata. File ends without a trailing newline, which is a minor formatting issue. | This chunk introduces LLM communication enrichment types, schema contracts, and audit/fallback helper functions, plus a refactor of identity validation into smaller functions. The code is well-structured with strict schema validation, bounded confidence values (max 0.85), and proper audit metadata. No security issues, command execution, secret access, or workflow modifications are present. Test results show passing checks with no failures. | This chunk refactors decodeIntakeResult, rejectSecrets, rejected, and related helpers in intake-protobuf.ts and intake-service.ts into smaller, more readable functions, and begins refactoring llm.ts to use extracted modules. The logic remains functionally equivalent to the prior implementation. No test failures are present in the provided test results data. | This chunk refactors the communication LLM enrichment module by extracting inline helper functions (e.g., enrichWithCorrection, fallbackOrThrow, participantGroups, promptPayload, validateEnrichments, materializeSyntheses) and types (e.g., CommunicationAttemptError) into separate, focused files (communication-llm-enrich.js, communication-llm-helpers.js, communication-llm-types.js). The main extractCommunicationIntentAudited function now imports these helpers. The logic appears functionally equivalent to the previous inline implementation. Type annotations were adjusted slightly (e.g., using as const for schema versions, inferring return types), but the overall behavior remains intact. No security issues or test failures were observed in this chunk. | This chunk contains a refactoring of glob translation logic in src/core/ignore.ts into smaller, focused helper functions (translateEscape, translateStar, translateCharacterClass) and the beginning of a recordStatement function in src/core/record.ts. The glob refactoring preserves the original logic equivalently while improving readability. The test results indicate all relevant checks are passing (PASS) or intentionally skipped (SKIPPING). | This chunk introduces a refactoring to split record-building logic into helper functions and adds new schema validation modules for code change plans and generation metadata. The code enforces strict schema validation, including exact key checks, enum validation, and semantic hash/id verification. Test results indicate all checks are passing. | The provided chunk introduces new schema validation logic for Intent records and generation metadata in TypeScript. The code is well-structured and includes comprehensive runtime assertions and validation rules (e.g., schema versions, fingerprint checks, exact key matching). However, there are concerns regarding type safety and unvalidated array elements that should be addressed before approval. | This chunk introduces validation primitives (schema-primitives.ts) and graph diff/relation assertion logic. The validation implementation is robust, including path traversal protection, acyclic dependency checks, and strong referential integrity enforcement. However, there is a critical security vulnerability in the path sanitization logic. The test_results_data contains only passing or skipping checks, so no failing tests are reported. | This chunk introduces schema validation primitives (exactCounts, isJsonValue) and a comprehensive schema-validation.ts module for grounded code change plans, TODO proposals, conclusions, and acceptances. The code performs thorough runtime validation with strict referential integrity checks (known IDs, acyclic dependencies, exact set matching). No security issues are present, and all provided checks pass. | This chunk contains schema validation logic for conclusions, TODO proposals, and validation context helpers. The code performs thorough validation including ID format checks, uniqueness enforcement, referential integrity, semantic ID verification, and exact-key object validation. No security issues or test failures are present in the visible chunk. | The visible chunk shows removal of legacy validation functions (assertIntentRecord, assertIntentGenerationMetadata, assertIntentGraph, assertIntentGraphDiff, etc.) consistent with a module split/refactor. This is a deletion-only diff segment with no new security concerns, no executable commands, and no test failures in the provided logs. | This diff chunk shows a large-scale removal (deletion) of validation logic across multiple functions including graph diff assertions, conclusion validation, TODO proposal validation, code change plan validation, and acceptance validation. Given the PR description indicates module splitting with barrel re-exports, this is likely code being moved to new focused modules. However, the chunk only shows deletions without the corresponding additions, making it impossible to confirm the validation logic was preserved in its new location. Critical validation functions (assertConclusion, assertCodeChangePlan, assertCodeChangeAcceptance, etc.) appear to be entirely removed in this chunk. Test results show all passing checks, which provides some confidence the moves are correct. | This chunk presents a validation refactoring for Code Change Plans, TODO Proposals, and Grounded Generation Metadata. The diff consists entirely of deleted lines, indicating that this logic is being moved or removed. The validation rules implemented are strict and generally sound, including schema version checks, regex ID validation, semantic version validation for runtime versions, and strict mode-based consistency checks for LLM generation metadata. However, there is a critical logical error in the refactored validation flow for TODO proposals that weakens the integrity checks. | This chunk shows a refactoring operation that removes inline validation helper functions from a schema module and replaces them with barrel re-exports of the same functions (e.g., assertIntentRecord, assertCodeChangePlan) from ./schema-validation.js. This is consistent with the PR's stated goal of splitting large modules into focused ones while maintaining the public API via re-exports. The deleted helpers cover robust input validation (path traversal prevention, ID pattern checks, acyclic dependency checks, hash/id verification) and are being moved rather than eliminated. | This chunk introduces foundational type definitions and refactors text inference utilities. The new types-foundation.ts and types-code-change.ts files define structured, non-executable contracts for code-change plans and Intent DSL records, emphasizing non-execution and explicit approval requirements. The text.ts changes simply hoist the OBJECT_ACTION_WORDS regex map to module scope for reuse, preserving the same regex patterns. No security issues detected in the visible code. | This chunk introduces new type definitions for the runtime pipeline manifest, audit trails, extraction results, and intent graph diagnostics. It also contains a large deletion of existing types from src/core/types.ts, likely relocated to types-foundation.ts or types-runtime.ts as part of a modularization effort. The changes are purely structural and do not contain executable logic. | This chunk shows removal of a large block of TypeScript type/interface definitions from a core types module, consistent with the PR's stated goal of splitting large modules (schema.ts, run.ts, llm.ts) into focused modules with barrel re-exports. The deleted types (IntentRecord, IntentGraph, CodeChangePlan, DiagnosticReport, etc.) are foundational domain interfaces being relocated. No logic changes, no security concerns, and no test failures present in this chunk. | This chunk introduces a refactoring of the TypeScript AST extractor, splitting a large visit function into smaller, focused helper functions (addDependency, visitNamedDeclaration, addVariable, addCall). It also shows the tail end of a type module split, where src/core/types.ts now re-exports from types-foundation.js, types-code-change.js, and types-runtime.js. Finally, it includes the beginning of a new communication-attribution.ts extractor module. The refactoring preserves the original logic and control flow, and the test results indicate all checks are passing. | The code chunk introduces communication attribution and envelope parsing logic. The logic is generally well-structured with proper fallback handling for metadata fields and participant identity resolution. However, there is a critical bug in the parseEnvelope function where the end delimiter is miscalculated, leading to malformed body content. | This chunk shows a refactoring of the communication extractor module. Types and helper functions are being moved from communication.ts into separate, focused files (communication-types.ts, communication-attribution.ts, communication-envelope.ts). The changes are well-structured, preserving existing functionality while improving modularity. Test results indicate all checks pass. | This chunk shows a refactoring that removes several internal helper functions from a communication extractor module (e.g., registryAttributionWarnings, resolveIdentity, parseEnvelope, inferIdentity, communicationSegments). The PR description indicates these functions were split into focused modules with barrel re-exports. The removed code does not introduce any security concerns, and the test results indicate all CI checks are passing. | This chunk primarily introduces refactoring changes, extracting inline logic into well-named helper functions across several modules (nl-llm.ts, docs-record.ts, linker.ts, a2a-card.ts, a2a-task-store.ts). The behavior of the code remains semantically intact, with control flow slightly restructured for readability (e.g., early returns in scoreTargetEvidence). No security vulnerabilities or test failures are apparent in the provided chunk. | This chunk introduces a refactor that splits the openrouter.ts client into focused modules (openrouter-parse.ts and openrouter-redact.ts) and extracts pagination and stage failure logic in a2a-task-store.ts and live/contract-check.ts. The security-relevant redaction logic is preserved and correctly handles untrusted provider error text by redacting credentials, secret assignments, and account-management URLs. The refactoring maintains the original behavior and types. All provided test results pass. | This chunk shows the refactoring of src/llm/openrouter.ts to remove inline helper functions (likely moved to focused modules like openrouter-parse.ts and openrouter-redact.ts) and the introduction of the new src/pipeline/pipeline-run.ts file which encapsulates the pipeline execution logic in a PipelineRun class. The code is cleanly structured, handles errors via persistFailedRun, and correctly tracks pipeline stages. The test results indicate all checks are passing or intentionally skipping opt-in/live tests. | This chunk introduces private pipeline stage methods (documentation extraction, configuration/runtime extraction, communication extraction, analysis, synthesis, planning, and summary auditing) refactored from a larger pipeline runner. The code is well-structured with clear stage tracking, audit generation, and graceful fallback handling when LLM keys are missing. No security issues, no secrets, and no command execution. Test results show all checks passing (skips are opt-in/live contract checks). | The provided chunk shows a large pipeline persistence and run-helpers module split. Code quality appears reasonable with structured audit tracking and output management. However, there is a high-risk security finding regarding path traversal in the output file writing logic that must be addressed before merge. | This chunk shows the extraction of pipeline helper functions (manifest configuration, failure handling, audit generation) from run.ts into a separate run-helpers.ts module, and the extraction of pipeline result types into run-types.ts. The code is well-structured, uses proper TypeScript typing, and the refactoring maintains logical separation of concerns. No security issues are present. Test results show passing checks with only opt-in/skipped tests omitted. | This chunk shows the removal of the monolithic pipeline/run.ts implementation as part of a refactor to split it into focused modules. The deleted code contains standard pipeline orchestration logic (extraction, analysis, synthesis, planning, persistence). The changes are consistent with the PR's stated goal of modularizing large files. No security issues are visible in this chunk. | This chunk shows a refactor of pipeline orchestration code, splitting large methods (extractCommunication, analyze, synthesizeTasks, planChanges, summarize, persist, etc.) into focused private methods. The code appears to be a pure extraction refactor with barrel re-exports. The diff shows removed lines from a larger file split, with logic preserved. No security issues are evident in this chunk. No test failures in the provided test results. | The provided diff chunk consists entirely of removed code from pipeline-run.ts, representing the extraction of functions into focused modules as part of a larger refactor. The code being removed deals with manifest configuration, persistence of failed runs, and diagnostic reporting. No test failures are present in the provided test results data. The refactoring logic appears sound, but the chunk is purely deletions and cannot be fully validated without the corresponding additions in other files. | This chunk introduces the reranker-types.ts and reranker-validate.ts modules, extracting them from reranker.ts as part of a larger refactoring effort to split core modules. The new validation logic enforces strict structural and semantic integrity for semantic candidate sets and rerank results, including ID format checks, duplicate detection, rank/score consistency, hash verification, and evidence grounding. The code appears correct and well-structured. No security vulnerabilities or test failures are observed. | This chunk refactors the semantic reranker module by moving types into reranker-types.ts and validation logic into reranker-validate.js, retaining barrel re-exports for backwards compatibility. The visible validation logic is robust, enforcing schema versions, hash formats (SHA-256), bounded scores, contiguous ranks, and grounded evidence quotes. No security issues or test failures are present in the provided data. | The diff chunk shows the removal of multiple validation functions (e.g., assertSemanticRerankResult, assertSemanticCandidateSet) and a type narrowing (satisfies SemanticRerankDecision -> inferred) from src/semantic/reranker.ts. This pattern aligns with a refactor to move these concerns into dedicated files like src/semantic/reranker-validate.ts. The new src/services/branch-snapshot-git.ts file introduces Git command execution using spawn. The implementation appears generally safe, using --end-of-options to mitigate argument injection and limiting output size. However, a critical input validation is missing for ref parameters in captureRef, which creates an argument injection risk if refs are untrusted. Additionally, without the full context of the newly created reranker-validate.ts, I cannot verify that all removed semantic checks have been preserved, posing a regression risk. | This chunk introduces branch snapshot Git service modules (types, validation, and capture/inspection helpers). The implementation shows strong security hygiene: spawning git with shell: false, validating repository-relative paths against absolute paths and .. traversal, enforcing strict regexes for SHAs/refs/patch IDs, and capping output buffers to prevent memory exhaustion. The code is well-structured and defensively validates untrusted Git output. No failing checks are present in the provided test results data. | This chunk refactors the branch snapshot module by splitting it into type, validation, and git implementation modules. The visible validation code (branch-snapshot-validate.ts) enforces strict, defense-in-depth input sanitization for git refs, paths, and SHAs, effectively mitigating path traversal and command injection risks. The branch-snapshot.ts file correctly re-exports the necessary types and functions from the new modules. | This diff chunk shows the removal of validation and helper functions from branch-snapshot-git.ts, likely moving them to dedicated modules (branch-snapshot-validate.ts and branch-snapshot-types.ts) as part of the refactor described in the PR summary. The logic being removed includes robust input validation (e.g., ref validation to prevent path traversal) and snapshot materialization checks. The PR body notes all tests pass locally, and the provided test_results_data shows passing checks for verify and code-review. | The visible diff chunk shows file deletions/removals of git command helper utilities (runGit, requiredGit, gitFailure, etc.) and the addition of a new acceptance evaluation module. However, the new file src/synthesis/code-change-plan-acceptance.ts appears truncated mid-function — closeCodeChanges returns an object but the visible code ends abruptly at acceptedCount, without closing the return object, function braces, or showing the remaining lines. Additionally, removing the git helper functions could break callers if those helpers were not relocated or if imports remain. Given the stated rules, I must not APPROVE when the provided code shows a syntactically incomplete file (even if this is a chunk boundary, the acceptance module's return statement is cut mid-expression). | The chunk implements applyCodeChangeSourcePatch with a strong security posture. Path traversal is mitigated via assertPathWithinRoot, symlink traversal is explicitly rejected, and a file lock prevents concurrent apply operations. The apply operation is idempotent and includes a rollback mechanism for partially applied patches. Receipts are strictly validated against the patch metadata. | Reviewing chunk 42 of 51: new files code-change-plan-helpers.ts and code-change-plan-propose.ts. The code includes robust validation for unified diffs (path traversal prevention, NUL byte rejection, and a regex-based secret assignment check) and strict source patch ID/string assertions. A createRepositoryPathProbe utility safely resolves paths within the repository root, returning true for escape attempts to degrade to a safer modify action. The visible test results show passing checks for verify and koru / code-review, with no failing checks present. | This chunk adds code-change-plan helper, generation, and review modules. The logic is pure and deterministic, with input validation (SHA-256 regex, ISO date checks) and clear schema assertions. The review brief explicitly avoids auto-applying source patches, requiring human/CI approval. No security vulnerabilities, command injection, or secret handling detected. | The visible chunk introduces robust schema validation for code-change-source-patch artifacts, including path traversal prevention (rejecting absolute paths and .. segments), strong ID/hash format assertions, and deterministic generation metadata. However, a type-casting concern is present where untrusted input is cast to a typed object before validation is completed. | This chunk introduces validation logic for code change source patches (assertCodeChangeSourcePatch, assertCodeChangeSourcePatchSet) and a unified diff parser (applyUnifiedDiffToText). The validation logic appears generally sound and correctly leverages assertions and fingerprint matching to enforce integrity. However, there are notable security and reliability concerns with the unified diff application logic, specifically regarding path traversal prevention and the potential for ReDoS via unvalidated regex inputs. | This chunk shows a module refactor where internal implementation details (interfaces, functions like proposeCodeChangePlans, evaluateCodeChangeAcceptance) are removed from a barrel/index file and relocated to focused modules. The public re-export export { isUsefulCodeChangePath } from './code-change-path.js'; is preserved. The visible code maintains safe path resolution in createRepositoryPathProbe and avoids marking work complete without human approval. Test results show all checks passing. | This chunk consists entirely of removed lines (deletions) from what appears to be a code-change-plan source file, removing helper functions like indexProposalsByDiagnostic, collectTarget, buildChanges, titleFor, confidenceFor, riskFor, rollbackFor, deterministicGeneration, and the createCodeChangeReviewPatch function. Since this is a barrel-split refactor per the PR description, these functions were likely moved to focused modules. However, the chunk shows only deletions with no corresponding additions visible, and I cannot verify that all removed exports (especially createCodeChangeReviewPatch, renderCodeChangeReviewMarkdown, and the exported interfaces) are re-exported from the barrel. The test results show all checks passing, which supports the refactor being complete, but a pure-deletion chunk in a refactor warrants verification that public API surface is preserved. | This chunk shows deletions of legacy source-patch/validation code, including robust path traversal guards (rejecting absolute paths and .. segments), SHA-256 hash assertions, and deterministic generation metadata. The validators reject non-relative paths, enforce unique edits, and verify schema versions. No security issues introduced; the removed logic appears migrated to focused modules per the PR summary. | This chunk shows deletion/rewrite of source-patch validation and apply logic (chunk 49 of 51). The visible code contains defensive validations: path traversal protection (assertPathWithinRoot), symlink refusal, foreign path detection in unified diffs, a lightweight secret heuristic in diffs, and explicit hash approval before applying patches. Test results show all required checks passing (verify PASS, koru/code-review PASS, Java adapter PASS). Skipping items are explicitly opt-in/governance, not failures. No security issues identified in the visible chunk. | This diff chunk shows the end of a large refactor: removing implementation details from a barrel/index file (replaced by re-exports from focused modules) and adding a new classifyWithModel helper in the TensorFlow classifier. The re-exports maintain the public API surface while relocating code to specialized files. The new classifier helper includes proper tensor disposal, probability bounds clamping, and a confidence threshold fallback. | This chunk contains a refactoring of the TensorFlow classifier to use a classifyWithModel helper, a structural refactoring of watchRepository to extract a WatchRuntime object for testability, and a new generated testql scenario file. The changes are low-risk and do not introduce any security vulnerabilities.
Advisory findings: Input contains a redacted environment variable line ([REDACTED_ENV_LINE]). Environment files and secrets must not be read, processed, or exposed. This is treated as a security-relevant finding requiring BLOCK.; No assertion-level test output provided. PR body states 421 passed / 1 skipped, but test_results_data only lists environment checks and skips; cannot confirm the claimed passing test suite for this chunk's affected modules.; {'file': 'src/core/schema-intent-validation.ts', 'description': "In assertIntentRecord, the target object's arrays (paths, symbols, tickets, versions) are validated using stringArray. It is assumed stringArray validates string elements, but if target[key] values are not properly checked for string contents, malformed data could bypass validation. More importantly, statement.target itself is validated but target is never explicitly assigned a type, relying on objectValue returning any or Record<string, unknown>, potentially allowing unexpected runtime behavior if stringArray is misused.", 'line': '53'}; {'file': 'src/core/schema-generation-validation.ts', 'description': 'In assertGroundedGenerationMetadata (visible at the top of the chunk), the property generation.configurationFingerprint is validated via fingerprint(). If generation contains additional unexpected properties, they are caught by exactKeys. However, the validation does not check if the fingerprint matches any expected computed value, only that it matches a format. This is a non-functional consistency risk if fingerprints are expected to be deterministic.', 'line': '13'}; Large deletion of security-relevant validation functions (assertConclusion, assertConclusions, assertTodoProposal, assertTodoProposals, assertCodeChangePlan, assertCodeChangePlans, assertCodeChangePlansForReview, assertCodeChangePlanForAcceptance, assertCodeChangeAcceptance) without visible corresponding additions in this chunk. While this is expected for a module-split PR, the validation logic for IDs, graph fingerprints, diagnostic references, and acceptance consistency is critical and must be confirmed preserved in the new modules.; {'location': 'src/core/schema-validation.ts (validateCodeChangePlanContext)', 'issue': 'Logical flaw in validation branching. In the else if (proposals.length) branch, the code iterates over proposals to build a referencedConclusionIds set. It then immediately iterates over proposals again to call assertTodoProposalValue(proposal, known.recordIds, known.diagnosticIds, referencedConclusionIds). assertTodoProposalValue enforces that conclusionIds must be non-empty and match the CONCLUSION_ID regex. However, because this branch executes when conclusions.length is 0, the referencedConclusionIds set is built from unvalidated proposal inputs (only checked for regex shape), but the actual conclusion objects are never validated. This allows a code change plan to reference arbitrary, unverified conclusion IDs. If this logic is being moved elsewhere, the destination must not replicate this flaw. If the intent was to validate full proposals when conclusions are absent, this implementation is incorrect and bypasses the assertConclusions integrity check.'}; {'file': 'src/extractors/communication-envelope.ts', 'line': 'findIndex and slice logic', 'issue': "In parseEnvelope, const end = lines.slice(1).findIndex(...) finds the index relative to lines.slice(1). However, lines.slice(1, end + 1) is used to parse metadata. If the closing --- is at absolute index 2, end will be 1. lines.slice(1, end + 1) becomes lines.slice(1, 2), which yields only the line at index 1. This logic appears to work for the metadata slice, but the body slice lines.slice(end + 2) is incorrect. If end is the relative index in lines.slice(1), then the absolute index of the closing --- is end + 1. Therefore, the body should start at absolute index end + 2, which means lines.slice(end + 2) is actually correct. Wait, let's re-verify. If lines = ['---', 'a: b', '---', 'body'], lines.slice(1) = ['a: b', '---', 'body']. findIndex returns 1 for '---'. end = 1. lines.slice(1, end + 1) = lines.slice(1, 2) = ['a: b']. Correct. lines.slice(end + 2) = lines.slice(3) = ['body']. Correct. No bug here. Withdrawing blocking finding."}; In writeIntentFiles, the file path is constructed as path.join(this.runDirectory, \${source}.intent.jsonl`)using thesourcekey directly fromthis.bySource(anObject.entriesiteration). If thesourcestring contains path traversal sequences (e.g.,../../etc/passwd), path.joinwill resolve it outside the intendedrunDirectory. Similarly, the outputPathsmethod constructs static filenames safely, but any caller-controlled or extractor-controlled data influencing filenames must be sanitized. Without validation that the resulting path remains withinthis.runDirectory, this is a potential path traversal vulnerability allowing arbitrary file write.; src/services/branch-snapshot-git.ts: captureRef(root, ref)uses therefparameter directly in Git commands (e.g.,['symbolic-ref', '-q', ref]). While rev-parsecommands use--end-of-options, symbolic-refdoes not. Ifrefis not strictly validated as a simple branch name and can contain shell-like arguments or option strings (e.g.,--upload-pack), it could lead to argument injection. Validate refformat strictly before use.; src/synthesis/code-change-plan-acceptance.ts: The closeCodeChanges function's return object literal is truncated atacceptedCount,with no closing brace, return statement completion, or function termination visible. If this is the actual file content, it will fail to compile.; Deletion of git helper utilities (runGit, requiredGit, requiredGitBuffer, gitFailure, parseCounts, etc.) from what appears to be branch-snapshot-git.ts — if any other module still imports these symbols, the build will break. No corresponding re-export or replacement is visible in this chunk.; {'id': 'BF-1', 'severity': 'high', 'file': 'src/synthesis/code-change-plan-unified-diff.ts', 'description': 'TheapplyUnifiedDiffToTextfunction processes diffs and constructs output strings. If this function is later used to write files to disk (as implied by the presence ofexpectedPath), it must ensure that expectedPathis validated against path traversal attacks (e.g.,../../etc/passwd). The provided chunk does not show the file writing logic, but the parsing logic itself does not sanitize or reject malicious paths. If the calling function relies solely on this parsing step, it may be vulnerable.', 'recommendation': 'Ensure that any caller of applyUnifiedDiffToTextstrictly validatesexpectedPathusingpath.resolve()andassertPathWithinRoot()before any filesystem writes occur. If this is already handled upstream, this finding can be downgraded, but it remains a critical boundary check.'}; Potential secret or sensitive environment variable detected in input. Even though redacted, the presence of an .env-style line indicates possible handling of secrets or untrusted sensitive data. Must not approve under these circumstances.; project2.sh performs unauthenticatedpip installof many unpinned external packages and directly executes installed CLIs over the repository; committed automation scripts that pull arbitrary latest package versions present a supply-chain risk. Recommend pinning versions and verifying provenance.; {'description': 'Inschema-primitives.ts, the repositoryPathfunction attempts to prevent path traversal by splitting on/and checking for... However, it performs this check AFTER normalizing backslashes to forward slashes but BEFORE checking for other encoded or mixed traversal sequences. More critically, the split on /will not catch..if it is not a standalone path segment (e.g.file..txtis allowed, which is fine, butfoo/..baris also allowed). If the intent is to block ALL parent directory traversals, a more robust approach is required. Given the context of repository paths, if this validation is the sole gatekeeper for file access, it is insufficient. If the path is strictly a logical identifier and not used for filesystem access, this is a lower severity issue. Assuming potential filesystem access based on the context.', 'severity': 'medium', 'location': 'src/core/schema-primitives.ts: repositoryPath function'}; Potential Path Traversal via unsanitizedsourcekey inwriteIntentFiles (path.join(this.runDirectory, `${source}.intent.jsonl`)). If sourceoriginates from untrusted input or file paths without normalization/validation, it could allow writing.intent.jsonlfiles outside the designated run directory.; Potential argument injection viarefparameter incaptureRef (symbolic-refcall lacks--end-of-optionsand pre-validation).; {'id': 'SEC-1', 'severity': 'high', 'category': 'Path Traversal', 'file': 'src/synthesis/code-change-plan-unified-diff.ts', 'description': 'The unified diff parser accepts anexpectedPathparameter. If this path originates from LLM-generated output or untrusted input and is subsequently used for file I/O operations (writes, modifications) without being normalized and constrained to an allowed repository root, an attacker could potentially write to arbitrary locations on the filesystem.', 'recommendation': 'Enforce strict path validation at the boundary whereexpectedPath` enters the system or immediately before any file operations are performed using the result of this function.'}
The LLM output above is advisory and was not used as the approval trust root.
Merge will be attempted after this approval when explicitly authorized.

Decision record (recomputable)

DECISION D-094-8706
TICKET ticket-094
HEAD_SHA 680944ff22ee2f429d044ec9b40d2150a1b494c5
CORRELATION_ID todo2code-pr-94-ticket-094
ACTOR agent:ifuri-validator-agent[bot]
APPLIED_RULE P-CORE-015
INPUT author_login = "tom-sapletta-com"
INPUT observed_checks = ["Live OpenRouter contract (opt-in)=SKIPPING","governance=SKIPPING","Java adapter (JDK 17 required)=PASS","verify=PASS","koru / code-review=PASS","governance=SKIPPING","Live OpenRouter contract (opt-in)=SKIPPING","Java adapter (JDK 17 required)=PASS","verify=PASS"]
INPUT required_checks = ["verify","Java adapter (JDK 17 required)","koru / code-review"]
INPUT required_checks_source = "protected registry + GitHub applied rules (env/request)"
INPUT reviewer_login = "ifuri-validator-agent[bot]"
VERDICT APPROVE AUTHORITY DETERMINISTIC
REJECTED REQUEST_CHANGES BECAUSE NO_UNSAFE_CHANGE_REASON_FOUND
ADVISORY llm_verdict = "BLOCK" MODEL "openrouter/z-ai/glm-5.2"
ASSERT VERDICT_AUTHORITY != "ADVISORY"