The implementation loop runs typecheck, unit and build. Golden, browser smokes,
performance and the full HA harness run before a beta — after the code review has
passed and the issue already sits in S8-merged. Some defects cannot surface any
earlier, and until now the process had nothing to say about them, so the honest
reading was a second full review cycle at the most expensive possible moment.
The owner's decision: fix it, re-run what failed, and a green run carries the
release on. The gate named the defect precisely and the same gate proves the fix,
so the check is objective and depends on nobody's judgement.
The boundary is written down with it, because "the gate found something" could
otherwise absorb an arbitrary amount of new work. A fix that changes a behaviour
contract, reaches an untouched subsystem or rivals the task in size goes through
the normal flow. Editing a test so it stops failing is concealment rather than
repair — the exception is a defect proven to be in the fixture, as on #89.
The rule also records what it costs: the author judges his own work here, which
the process refuses everywhere else. That is the price of speed at the one point
where a review cycle is dearest, and the compensation is that the re-run command
and its result are written into the issue where the release manager reads them.
Issue: #114
User-Visible: no
A review run always moves the label. The rule is written down because its absence
cost a real stall: a green code review whose merge conflicted left the label alone,
the waiting author polled thirty times and reported the limit as exhausted, and a
verdict that existed reached nobody.
Both documents now say what S6-in-progress means when the verdict was green and
only the merge failed — rebase, not rework, and the verdict still stands. They also
say that a label which did not change means the run failed rather than the work, so
the answer is logs and the owner, not more polling. Cycles are counted per stage.
Issue: #114
User-Visible: no
docs/specs/README.md kept a "Статус ТЗ" column with its own vocabulary — draft,
in implementation, done — next to the labels that already hold the status. Two
dictionaries for one fact drift apart, and these had: the column still called
issues "in implementation" that were closed weeks ago. The table now says only
which issue a spec belongs to.
AGENTS.md was telling agents that PROCESS.md §1 does not cover package.json and
the rest of the configuration, and to report it as missing. It covers them now.
The same paragraph gained the rule that D beats A where paths overlap, which is
what keeps the built bundle under custom_components/houseplan/frontend/ from
reading as product source.
Issue: #119
User-Visible: no
Practice had already diverged from the documents: #105, #112, #114 and #116 were
all done without a spec and without review, and that was right. Nothing said it
was allowed.
The test is mechanical — not a single class A file — rather than left to the
executor's judgement, because a loose reading is exactly how product changes
would learn to skip review.
Issue: #118
User-Visible: no
Review fires from the label and runs on its own, but nothing was picking the
result up: the author reported "handed over for review" and stopped, so the
conveyor stalled until the owner said a sentence. The author now polls the label
and continues from whatever it became.
Also drops the merge-into-dev standing permission: the pipeline does the merge
before setting S8-merged, so a hand merge would race it.
Issue: #114
User-Visible: no
Agents were escalating technical calls. The owner answers what a person sees
or does and how much user-visible change belongs in an issue; storage, module
layout, naming, test strategy and migration mechanics are settled by the
agents, recorded as assumptions and challenged in review.
Issue: #114
User-Visible: no
Without it S8-merged would be a lie: the label asserts the code is in dev,
while the branch-only push leaves it on the task branch. What lands is what
the reviewer just accepted, and dev is allowed to carry unreviewed code
anyway, so the merge adds no risk the branch did not already carry.
Issue: #114
User-Visible: no
The reviewer runs in CI and can only read the remote, so an unpushed spec or
commit either stalls the review or points it at the wrong tree. Pushing
issue/<NN>-slug now needs no command; dev, main, merges, tags and releases
still do.
Issue: #114
User-Visible: no
Publishes the 538-line process canon into the repository, replacing the
51-line provenance stub that pointed at a non-existent .agents/PROTOCOL.md.
Rewrites AGENTS.md: product context first, labels as the canonical status,
rule #1 with the status check, change classes, trailers, push cadence,
Codex/Claude roles and review cycle limits.
Issue: #112
User-Visible: no
Matysh