jbaruch / jbaruch/coding-policy

fix(herdr): Tighten approach-reference validation and the initial direction's identity

Open
#468 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1
Forks
2
Avg merge
9h 22m
Merged PRs (30d)
81

Description

Two advisory findings from Copilot on #467, deferred there under rules/review-severity.md (no blocking round was in flight, and neither gates).

1. A diagnosis's approach reference is not checked against its own task

validate_store confirms that a diagnosis's approach and approach_change name some recorded approach, never that the approach belongs to the same task:

for row in store["diagnoses"]:
    if row["approach"] is not None:
        _item(store["approaches"], row["approach"], "approach")

A hand-edited ledger pointing a diagnosis at another task's approach passes validation, and current_diagnoses then drops that row from its own task's ladder — so the per-approach ladder and stop checks skip it. Reject a non-null reference whose approach record carries a different task, and do the same for approach_change.

2. The initial direction has no comparable identity

_require_new_direction compares against approaches rows, and the initial approach deliberately has none (nothing approved it; inventing one at registration would make existing ledgers claim a transition that never happened). So a judge can declare the task's original direction as APPROACH: and receive a fresh allowance, which the contract means to refuse.

The guard works from the first transition onward, which is where a replayed direction is actually reachable. Closing the gap needs the initial direction recorded somewhere comparable — a direction on the task record, which every existing task record lacks. Decide whether that is worth a task-record schema bump, or whether the judge brief's wording is the right place for it.

Not in scope

Two other Copilot findings on #467 were checked and are wrong:

  • A diagnosis-created approach records supersedes: null — correct, because active_plans already retires the plan through the diagnosis's own supersedes. Verified: the plan is absent from active_plans.
  • The fix_round > DEFAULT_FIX_LIMIT history check at recovery.py would reject a valid fresh-approach dispatch — it requires a dispatch record, not a plan, and every apply writes one. test_an_evidenced_change_of_approach_starts_a_fresh_allowance spends cumulative 6–10 under a fresh approach and validate_store passes. The suggested change would weaken a still-correct invariant.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing validate_store, current_diagnoses, and _require_new_direction, then read rules/review-severity.md for the deferred findings. Check recovery.py and test_an_evidenced_change_of_approach_starts_a_fresh_allowance while deciding how the initial direction should be represented. Done means cross-task approach references are rejected and replaying the initial direction cannot receive a fresh allowance, with existing ledger validation preserved.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.