openreachtech/hora-core/hora-accept

hora-accept

Acceptance. Run the unit suites in full, run the acceptance review at the reach this invocation calls for, and record the result — including what that reach was.

Read ../hora/references/structure.md first. This skill is strictly read-only on `specs/`, and it never fixes code. It finds and records; fixing is a checkpoint's job, in /hora-build.

What this skill does not contain

The content of an acceptance review, and the criteria it passes or fails on, are not in this file and must never be written into it. They live in the @openreachtech/hora-skills-ort-* packages, and this skill delegates the work.

What this skill decides is only three things: which features are in scope, in what order the delegates run, and where the result is recorded.

No name appears above, and none may

A skill's name belongs to the package, which is free to change it (../hora/references/structure.md, "No hora file ever names one of those skills"). A renamed skill does not disagree with this file — the name stops matching, and the step is skipped while the record says the run passed.

So this skill matches at run time, itself, against the equipped skills' own descriptions, before running the step. Record the names it picked in the run's own record — the Delegate column below is that record.

If nothing equipped covers a row, say so and continue without it. Record the gap by the work that went uncovered. Do not substitute a guess, and do not invent the missing criteria yourself.

What is in scope

Two invocations, two reaches — and the unit suites are the one thing that never shrinks.

Step 6 is the one step whose scope is not a feature set. At the sweep it is pointed at the repository whole; at a gate it does not run, because checkpoint 8 already audited that feature's change set (../hora-build/references/checkpoints.md, checkpoint 8).

"Explicitly requested" means a person asked for it, in the run. That is the only widening there is, and the run records it with the requester named. Nothing here upgrades a gate run on its own judgment, and nothing downgrades the sweep.

A widening changes the reach and nothing else — least of all where the record lands. A gate run asked to reach every done feature is still that feature's acceptance, so it appends a block to that feature's own file and says reach: full inside it. There is no third kind of run and no third path.

The version's own acceptance criteria are a third thing in scope, and they are the sweep's alone. A behavior spanning several features reaches no gate at all (../hora/references/spec-format.md, "15. Version acceptance criteria"). _plan.md's ## Acceptance entry names how many there are and which rest on a feature nobody accepted.

A widening does not reach them either. A widened gate run is still accepting one feature, and these criteria are a statement about the version. Judged at a gate, a criterion spanning three features would fail against a product holding one of them.

A standing policy could not live in `_plan.md`, which is why the widening is a person and not a line. .hora/ holds derivations, written by skills and read by humans (../hora/references/structure.md, invariant 1). If a project wants "sweep live at every gate" as policy, it belongs in the spec.

A feature implemented before Hora Kit was adopted is in scope like any other. Its checkpoints are marked not-applicable up to the acceptance gate, never through it — so the first sweep after adoption is the run that says what the existing product actually does. Expect findings there.

A feature the spec only listed is the opposite case, and the derivation has already decided it. /hora-plan writes its entry under ## Not accepted, with no checkbox at all. Scope above is read off those checkboxes — a gate run takes the feature whose gate it is, a sweep takes every entry that is [x] — and an entry with no checkbox is neither. It is therefore out of scope at this version and at every later one, with nothing added here to keep it out.

No box at all and an unticked box are two states, and only the first one is this. [ ] says a run is going to close this entry (../hora-plan/SKILL.md, "collapses to one sweep"), which is why the row above takes a collapsed version's feature entries into scope whatever their boxes read. Absence of the box, never its state, is what puts a feature out of scope.

That section is taken by what it is, not by an exact heading string: the version's feature section, whatever its heading reads. A collapsed version's is written ## Features — adopted as built, so a selector matching a bare ## Features literally finds no section in precisely the version whose every feature it was supposed to cover. Match the section, then read its entries.

Deriving the exclusion rather than writing a rule for it is the point. A rule would have to hold at two reaches, three invocation forms and every version after this one, and the first place somebody forgot it would put a feature with no acceptance criteria in front of the review skills — which can only report that nothing failed. The checkbox is absent once, in the plan, and every reach reads the same absence.

Where the plan collapsed a version into a single adoption sweep, that sweep is one invocation with every adopted feature in scope, standing in for each one's checkpoint 18. It runs the same six steps as any sweep — only the number of repetitions shrinks. Its findings route to checkpoints per feature, and a feature a finding reopens gets its checkpoints back for real.

A feature whose acceptance was deferred by a listing runs at full live reach when it is finally accepted, whatever the invocation form. It is decided mechanically, from two facts together: no `.hora/acceptance/*/<feature-id>.md` holds a block whose verdict is a pass, in any version, and an earlier version's `_plan.md` names this feature under `## Not accepted`. Such a run is the only acceptance this code will ever have had, so a live-skipped pass would stand as the whole of what was ever said about it.

Both facts are needed, and the second is what keeps this from swallowing the gate's own default. Every feature's checkpoint 18 is its first acceptance, so the missing file alone would widen every gate run ever. A listing is what makes this run different: the deferral was declared, in the spec, and this is the run that pays for it.

It matters most where the missing record is years old. The invocation says nothing about the feature never having been accepted, and the person invoking it has no reason to know. The plan and the absent file are what say so, identically whether the listing is one version old or four.

The regression net at a feature gate is the unit suites plus the review's own static checks, and it is cumulative by construction. The suites run whole repositories, so a feature that breaks an earlier one fails here, in the run that broke it. What a gate run gives up is driving every earlier feature's screens end to end; that is the sweep's job, and the record says which reach its verdict was reached at.

[wing] Whether a feature gate drives the product live

Yes, where a person asked for it in the run, or where this run is paying a listed feature's deferred acceptance (both above). Otherwise the gate keeps the static checks and gives up the driven ones. The sweep always drives, so this section never reaches it.

The order to run in

Each step below states the work, not a name. Match it against the equipped skills' descriptions first, then run it, and write the names you matched into the record's Delegate column.

1. Confirm the environment — when the live sweep is going to run
     as "How to confirm the environment", below, says
     Not satisfied -> stop. Report `lacked-environment` (blocking: yes).
                      Do not review a frontend served on its own, and do not
                      "work around" a missing service
     A gate run whose live sweep is skipped neither requires the stack nor
     brings it up — the review's own capability note then records that
     nothing in its verdict rests on a driven browser. A gate run paying a
     listed feature's deferred acceptance drives, so it needs the stack