Open_Ultra_SAST/.kiro/specs/pre-push-safety-net/task-review.md

Task-plan review: pre-push-safety-net

Date: 2026-09-12. Scope: design readiness and implementation task graph, not runtime validation.

Authorization and phase

After the amended requirements/design and JavaScript transfer plan were presented, the maintainer said "ok, next kiro phase". This was applied as approval of those concrete documents for task generation. Requirements/design are approved; generated tasks remain unapproved and implementation has not begun. The initial acceptance profile is an evaluation target, not a demonstrated SLA.

Design readiness assessment

GO for task generation. The design retains the existing ranker as scope owner, excludes vendor code from targets/graphs, preserves language-agnostic evidence contracts, and separates graph claims from actionable change-related alerts. Boundaries, integration paths and all 35 numeric requirements have concrete design counterparts. No fundamental design gap was found in this review.

Three material risks are explicit work and release gates, not assumed solved:

1. Whole/changed-unit graph cost may not meet the hook deadline: measure the uncached baseline before cache work, then realistic warm edits rather than identical-tip hits alone (5.2, 8.2).
2. Frontend/framework or sanitizer semantics may prevent an actionable claim: retain the gap, keep the affected capability experimental, and route new engine work to its owning spec (3.3, 8.3).
3. Repeatedly inspected examples do not prove transfer: freeze the core and retain untouched evidence per language/framework/family, with noise/recall/coverage gates together (1.2, 8.3).

Independent task-graph sanity review

Reviewer received the draft task plan and paths to requirements, design, evaluation and task rules, without a parent-generated coverage summary. The first verdict was NEEDS_FIXES:

• Cache reuse can complete more work within the same deadline. Task 6.4 must require evidence/ admission equality for the same completed questions; complete-scope equality belongs to a controlled sufficient-budget comparison, not every deadline-limited run.
• Requirement 8.1 needs explicit paired normalized PHP/JavaScript contract tests, including equivalent capability eligibility and an unsupported-origin negative control (3.2, 4.2).
• A Node holdout cannot admit PHP or Python capabilities. Untouched evaluation is required for each language/framework/family; missing evidence leaves that capability experimental (1.2, 8.3).

All three were repaired once. The same independent reviewer read the repaired draft and returned PASS, with no remaining important task-graph issue. No return to design was required.

Mechanical and scope checks

• Eight major groups and 27 executable subtasks; one parallel candidate (3.1), otherwise sequential because the work shares backend, ranker, cache and integration contracts.
• All 35 requirement IDs mapped; every executable subtask has an observable completion condition, responsibility boundary, and valid explicit dependencies where needed.
• No task is checked off; no acceptance-critical tests are optional. No deployment is included.
• The initial experiment is 5.2; persistent caching follows it. Normal alert eligibility is gated at 8.3, so experimental diagnostics do not become noisy advisory output during development.
• Final file/metadata validation and git diff --check are the fresh document checks. No runtime code or tests changed, and no graph/performance measurements were rerun during task generation.

Next phase: human task approval, then implementation starting with group 1.