@erclx/aitk 0.90.0 → 0.91.0

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "aitk",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "0.90.0",
+  "version": "0.91.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/claude-address-review/REQUIREMENT.md

@@ -11,6 +11,8 @@ Without this skill, review findings are worked in whatever order the author read
 
 A branch also goes stale from `main` moving rather than from anything the branch did. Nothing in the return leg rebases it, so the worker closes every finding, reports the pull request answered, and the branch still cannot merge. Half the resolution is mechanical and wrong to do by hand, since a generated file merged manually produces a diff the next regen discards.
 
+A declined finding fails on a third axis, which is where its reason ends up. A worker answering a dispatch by naming the plan question that already settled the finding, or the constraint the diff never showed, settles it in whichever session heard the answer. Both sessions end, so a reader opening the thread later finds a finding that stopped being mentioned and no record of what stopped it, which is the durability the posted review already has by design.
+
 ## Must
 
 - Treat a failing check as a finding alongside the review comments, so the follow-up closes both
@@ -22,6 +24,7 @@ A branch also goes stale from `main` moving rather than from anything the branch
 - Rebuild a generated file through the project check rather than resolving its conflict by hand
 - Push before replying, so the comment never runs ahead of the code it describes
 - Map every finding to what changed, or to a one-line reason when it is a question or a conscious accept
+- Carry the fact behind a declined finding into the posted reply rather than into the message that answered the dispatch, since both sessions end and the thread is what the next reader opens
 - Post the terminal comment only when the findings are addressed and every check passes
 - Say what the run actually did on a rebase-only pass, since a reply mapping findings and a terminal comment claiming they were addressed are both false on a pull request carrying none
 - Scan the reply for banned characters and internal phase labels before posting, since the comment leaves for the remote unchecked
@@ -33,6 +36,8 @@ A branch also goes stale from `main` moving rather than from anything the branch
 - Post the closing comment while a check is failing
 - Reimplement the follow-up push or the doc refresh. Both have owners, and a second copy here drifts from them.
 - Edit silently. A finding answered without a reply leaves the reviewer re-deriving the change from the diff.
+- Answer a finding in the channel alone. A reply that changes what the review concluded is the one the thread has to carry.
+- Post a correction to what the reviewing session believes about the world. That class changes no finding here and belongs in the session record.
 - Take one side of a conflict wholesale. Both sides are valid content, so `--ours` or `--theirs` drops one silently and passes every check.
 - Merge `main` into the branch. The repository squash-merges, so a merge commit reads as noise on the pull request.
 - Guess at a hunk the tree does not settle. That case reaches the operator as an ordinary finding on the next pass only if the worker stops.

package/claude/skills/claude-address-review/SKILL.md

@@ -114,6 +114,23 @@ bullet per finding, each opening with the bolded finding identifier.
 Close the body with `🤖 Addressed by Claude Code` on its own line so the reply
 reads as an independent machine pass, not a human sign-off.
 
+A finding this run declined carries the fact that settled it, inside its own
+bullet rather than in a section of its own. Name the plan question that already
+answered it, the constraint the diff does not show, or the measurement the
+reviewer did not have. Answering the dispatch in the channel and leaving that
+fact there loses it when both sessions end, and the reviewer is left with a
+finding that stopped being mentioned. The rule fires on a bullet the body already
+writes, so nothing depends on judging mid-reply whether a reply was important.
+
+The rule reaches a finding and nothing else. A correction to what the reviewing
+session believes about the world, such as which session holds which branch or
+what an edit passes through before it lands, changes no finding on this pull
+request and belongs in that session's own record rather than on a thread that
+closes. Keep it off the comment, and answer it wherever the dispatch reached this
+session when one did. Nothing tests the reply for either rule, since the scan
+below reads it for banned characters and phase labels alone, so both halves hold
+while a run applies them.
+
 When step 5 rebased the branch, say so in the summary sentence and name which
 files were resolved by hand and which the regen rebuilt. The next review is a
 full pass rather than a delta, and the reader is owed the reason.

package/claude/skills/claude-orchestrate/REQUIREMENT.md

@@ -33,6 +33,8 @@ The runbooks the session cannot run from memory fail on a third axis, which is w
 
 Every one of them therefore has to ship inside the skill, the four covering the moments the loop cannot detect and the fifth holding the review trigger. That last one fails on an axis of its own, since it names one client's command as the way to start the loop, so a session holding a different recurring-prompt scheduler reaches no path and a client without that command reaches none either, and the file ships to every target holding the plugin.
 
+The dispatch's return leg is unplaced for the same reason. A reply reaches this session as a message and settles a finding, corrects which session holds which branch, or names a gate a worker's edits pass through, and reading it is the whole of what happens to it. Both sessions then end, so the half that belonged on the pull request never reaches it and the half that belonged on the board is rediscovered by whoever needs it next.
+
 The session also records nothing of what it learns. Both other callers of memory capture are ship-chain skills and this one never ships, so the session taking every operator correction is the session with no moment that writes one down. Hanging that moment on the merge sweep answers it and bills the operator a capture pass per batch of merges while nothing is being built, which is a cost paid on the days shipping is fastest.
 
 ## Must
@@ -42,6 +44,7 @@ The session also records nothing of what it learns. Both other callers of memory
 - Verify a plan against the tree before handing it over, counting the sites it claims and opening the files it describes
 - List a candidate's file set against every track in flight, and serialize when the sets are not disjoint
 - Place every finding a merged pull request produced against the surface that owns it
+- Place what the return leg carries by what it changes, sending an answer that settles a finding onto the pull request and one that corrects this session's model of the world to the task owning that surface, since neither becomes a record by being read
 - Date the roadmap line from that file's last commit, so an old sequence reads as old
 - Keep one planned, non-conflicting task in reserve beyond what is running
 - Refill the queue while a wave is still building, rather than on a merge and a thinning list alone, since neither of those fires across the window planning costs nothing

package/claude/skills/claude-orchestrate/SKILL.md

@@ -120,6 +120,8 @@ A session is reachable when it appears in a live listing, which reads what each
 
 The channel runs both ways and the return leg carries what the pull request cannot. A worker answering a posted finding by naming the plan question that had already declined it changes the outcome in the moment, where a thread comment waits on whoever reads it next. Read what a worker volunteers as part of the review rather than as an aside.
 
+What arrives there does not become a record by being read, so place it by what it changes. An answer that settles a finding goes onto the pull request through the next pass, which withdraws or regrades that finding and names the fact behind it, per `claude-pr-review`. An answer that changes what this session believes about the world instead, which is a mapping correction or a constraint on what a worker can do, settles no finding and reaches no thread, so route it the way Boundaries below routes a change found while orchestrating, which lands it on the task owning the surface it describes. Writing a tracked file to hold either is forbidden here, which leaves the pull request and the board as the two surfaces this session writes.
+
 A plan written here is written against a tree several branches are already changing, so it names the file set of every track in flight as a constraint, one set per track, read from the Touches column of that track's row. State for each set which of the two acts it forbids, per Constraints in `.claude/standards/plan.md`, or `${CLAUDE_SKILL_DIR}/../../standards/plan.md` when the project does not have it. A bare path list leaves the worker guessing, which is how a plan ends up forbidding the repair of a citation the change broke.
 
 ## Boundaries

package/claude/skills/claude-pr-review/REQUIREMENT.md

@@ -9,6 +9,8 @@ description: What the independent pull request review is for, the gaps it closes
 
 Without this skill, a pull request is reviewed only by the session that wrote it, which cannot see the roadmap sequence or a sibling branch in flight. Findings land in chat, where they are read once and leave the thread with no record. A review that opens and never closes is worse than none, since a reader scanning the thread cannot tell an unanswered review from a confirmed one, and the author's claim that findings are fixed is the only evidence they are.
 
+A finding also stops being true by argument rather than by a fix. A worker naming the plan question that already declined it, or a constraint the pass could not see, settles it in the exchange that carried the answer, and the pass that accepts the argument drops the finding from its next body. A reader then sees a finding raised once and never mentioned again, which is indistinguishable from one everyone forgot.
+
 ## Must
 
 - Post until the review closes. A first pass opens against the whole change, and each later pass checks whether the prior findings landed.
@@ -17,6 +19,7 @@ Without this skill, a pull request is reviewed only by the session that wrote it
 - Scope a later pass to the commits added since the prior one, once that commit is confirmed to still reach the head
 - Apply the integration, contract, and consumer lenses a self-review structurally cannot
 - Post the closing pass even with nothing to report, since a review left unanswered reads as one nobody closed
+- State a withdrawal or a regrade on the thread with the fact that settled it, since a finding dropped in silence reads the same as one nobody answered
 - Key the body file on the pull request number and the head commit, and on the response it answers once the head repeats, so no two passes overwrite each other
 - Scan the comment for banned characters and internal phase labels before posting, since a finding phrased against a phase label reaches a reader with no task board
 

package/claude/skills/claude-pr-review/SKILL.md

@@ -87,6 +87,8 @@ Apply the high-signal filter: flag only what will cause incorrect behavior, brea
 
 A later pass applies the same axes to the delta, and adds one check the first pass cannot make: did each prior finding land, and did the fix regress anything it touched. Findings of its own are normal findings, stated at the same severity and counted the same way. That count is what Step 4 reads to pick the heading, so a pass raising one of its own is not a close-out.
 
+A prior finding can also be settled by argument rather than by a fix. A reply naming the plan question that already declined it, or a constraint this session could not see, withdraws the finding or moves its grade. State that outcome in the body under the finding it changes, naming the fact that produced it, whether the argument arrived on the thread or through the channel that carried the dispatch. Dropping the finding from this body instead leaves a reader unable to tell a withdrawal from an oversight, and the reasoning goes with the session that heard it. A withdrawal removes the finding from the count, so a pass that withdrew every open item is a close-out. Write the withdrawal and its cause into that body rather than taking the short close-out line Step 4 supplies, which reports prior findings addressed and would credit a fix nobody made.
+
 Use severity: `critical` (blocks merge), `should-fix` (fix before merge), `minor` (visibility only).
 
 ## Step 4: post to the PR
@@ -166,6 +168,8 @@ gh pr review <number> --comment --body-file .claude/.tmp/pr-review/body-<number>
 
 A pass with no findings takes `## Review closed` and a short body, with the footer line included either way. On a first pass, post `✅ No blocking findings. Reviewed against project docs and roadmap.` On a later pass, post `✅ Prior findings addressed. Re-reviewed <short-sha>, N commits since the prior pass.`
 
+A pass that closed by withdrawing a finding rather than by reading its fix takes neither line, per the withdrawal rule in Step 3. Both claim a fix landed, and the second names it, so posting either over a withdrawal credits work nobody did on the one comment a reader treats as the verdict. Write the withdrawal and the fact that settled it in place of the canned line, keeping the heading and the footer.
+
 Post that one even when there is nothing to report. A review left with no closing comment reads as one nobody answered.
 
 ## Step 5: output

package/docs/operating-model.md

@@ -74,6 +74,19 @@ reply that changes an outcome, such as a worker naming the plan question that
 already declined a finding, still belongs back on the PR, since the session
 holding it ends and the thread is what a later reader opens.
 
+Two rules put it there rather than leaving that to whoever remembers. A finding
+the worker declines carries the fact that settled it in the same reply body that
+already maps every finding, and a pass accepting that argument states the
+withdrawal or the regrade with what produced it instead of dropping the finding
+from its next comment. Both fire on a line the body already writes, so neither
+asks a session to judge mid-reply whether its own message mattered.
+
+A reply that corrects the reviewing session rather than a finding stays off the
+thread. Which session holds which branch, or what gate a worker's edits pass
+through, changes no finding on a pull request that closes, so it goes to the task
+owning that surface. Nothing checks either rule, so both hold while a session
+applies them.
+
 A finding answered without a commit leaves the head where the first pass read it,
 which a gitignored record and a finding accepted as recorded both produce. The
 close-out is still owed there, since the newest heading is what tells an operator

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/aitk",
   "type": "module",
-  "version": "0.90.0",
+  "version": "0.91.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {