Kernel: a request for changes from a person with write access #34

Activity

1. don-petry

   added a parent issue on Oct 11, 2026

   • Epic: nine gaps in the Kernel, found in review #29
2. don-petry commented on Oct 14, 2026

   

   don-petry

   on Oct 14, 2026

   ContributorAuthor

   More actions

   #34 Kernel: a request for changes from a person with write access

   Working ruling (Solution Architect, delegated). The Maintainer may overturn it in review.

   Question. Does a request for changes from a person with write access gate, sending the Work item back to its author, or Hold it until that person acts?

   Options.

   1. It gates, as that person's thread does: the author's Run answers it, then the item waits for that person.
   2. It Holds: no Run is admitted. The author never sees the request, so UJ-4's "the next run includes that input" fails.
   3. Keep today's behaviour and read threads only. An ordinary review then blocks nothing, which is L-14 again.

   Ruling: 1. UJ-4's climax is that the Maintainer "can block an agent's pull request with an ordinary review". FR-25 puts that review into the next Run's Task. FR-33, §4.2 item 3 and decision 0007 already make it a human Finding.

   • The request stands until that person approves or dismisses it. New content does not clear it, because GitHub keeps it standing across pushes and L-17 forbids a Role from closing a person's objection.
   • A later review that only comments does not clear it.
   • A request for changes from a stranger or a Lens gates nothing (§4.6).

   Acceptance criteria.

   1. Each review carries by {kind, name, can_write}, as a thread's opened_by does, plus submitted_at, and the state dismissed. These go into schemas/facts.schema.json, examples/facts.json, tests/support.py and sim/world.py, with the counter-example examples/invalid/facts.review-without-reviewer.json.
   2. test_a_writers_request_for_changes_does_not_converge is reshaped and has @pending removed. It gives addressing and human_finding, and admits a fix Run. After the author's Run it gives awaiting_human and needs_you. The one function whose_turn serves both threads and reviews.
   3. test_a_request_for_changes_stands_until_that_person_reviews_again and test_a_strangers_request_for_changes_does_not_gate.
   4. One mutant for "a writer gates" and one for "new content clears it".

   Documents: design §3.3 reviews; decision 0007 and L-14.

   Confidence. High. I would rule otherwise if the reader App's credential cannot see a reviewer's write access (L-57).

   Needs the Maintainer? No. Decision 0007 already rules that it gates.
3. don-petry commented on Oct 14, 2026

   

   don-petry

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Amendment (Solution Architect working ruling on #20, 2026-10-14): reviews also carry dismissed_by. Only that person's approval, or a dismissal by a person with write access, clears a request for changes. A dismissal by an App does not, because the reviewer's App holds pull_requests: write and GitHub cannot grant less.
4. don-petry

   closed this as completedin #87on Oct 15, 2026