From 5c49382aa020e5e76d4df693fbccdf487474e859 Mon Sep 17 00:00:00 2001 From: Phil Leggetter Date: Mon, 21 Sep 2026 19:26:06 +0100 Subject: [PATCH 1/3] Separate issues we fix from issues we file elsewhere `finding` held both product facts and defects in our own instrument, near enough evenly, which is the conflation the release-notes rules already guard against. It is now `product`, and the three instrument defects it carried moved to `harness`. A `product` issue carries an `Owned by:` line naming the repository and the title the issue would take there, because the label says the fix is elsewhere and only that line says where. Co-Authored-By: Claude Opus 5 (1M context) --- AGENTS.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index cd17099..50568cf 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -181,6 +181,41 @@ gh issue view # the detail and any discussion gh issue list --state closed # what was already decided, and why ``` +**Two labels say who fixes the thing, and they are the first filter on that +list.** `product` is a fact about Hookdeck, its docs or its skills: the fix lands +in another repository, and the issue here is the record that the benchmark found +it. `harness` is ours — runner, scorers, provisioner, seeds and CI — and can be +picked up in this repo. The other labels — `scenario`, `publishing`, +`documentation` — say what an issue is about rather than who fixes it, and appear +on either side: #43 is `product` and `scenario`, because the API fix is elsewhere +and the scenario it suggests is ours. + +The two are otherwise indistinguishable on a board and have opposite next +actions: a `product` issue needs filing elsewhere and then measuring, a `harness` +issue needs a pull request here. `product` was called `finding` until 21 +September and carried both: three of its eleven issues were defects in our own +instrument and moved to `harness`. That is the same conflation the release notes +rule against, where an open defect in our instrument is neither a product finding +nor something shipped. + +**A `product` issue carries an `Owned by:` line at the top of its body**, naming +the repository and the title the issue would take there: + +``` +**Owned by:** `hookdeck/core` — "Say the project is not an Outpost project instead of returning Not Found" +``` + +The label says the fix is elsewhere; only that line says where, and working out +where is the expensive half. Name both repositories when a finding splits across +them, as #34 does — documentation in `hookdeck/outpost`, behaviour in +`hookdeck/core`. Where you cannot tell which repository owns it, write that in +the line rather than guessing: an issue filed against the wrong repository is +worse than one not filed. Replace the line with a link once the issue exists. + +A `product` issue is closed by the release that measures the change, not the one +that ships it — the mapping-issue rule under Releases — so one sitting open after +its fix merged elsewhere is in the correct state. + The division of labour between the three places, so nothing is duplicated: | | | From d159412da1e69d917876d26103d6c2d3de8abaf1 Mon Sep 17 00:00:00 2001 From: Phil Leggetter Date: Mon, 21 Sep 2026 22:53:42 +0100 Subject: [PATCH 2/3] Say which `product` issues have no owner elsewhere MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Nine issues carry `product` and two of them — #2 and #27 — have neither an `Owned by:` line nor a fix in another repository, so the rule as written reported two issues as drift on the day it was written. Both shapes are real and worth naming: a question about our own skills does not know its repository until it has an answer, and a mapping issue already links the change it is waiting to measure. The definition also claimed a `product` issue is the record that the benchmark found the thing, which #43 opens by denying, and the history sentence recorded three issues moved rather than the five the triage found. Co-Authored-By: Claude Opus 5 (1M context) --- AGENTS.md | 38 +++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 50568cf..7bfd346 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -182,21 +182,27 @@ gh issue list --state closed # what was already decided, and why ``` **Two labels say who fixes the thing, and they are the first filter on that -list.** `product` is a fact about Hookdeck, its docs or its skills: the fix lands -in another repository, and the issue here is the record that the benchmark found -it. `harness` is ours — runner, scorers, provisioner, seeds and CI — and can be -picked up in this repo. The other labels — `scenario`, `publishing`, -`documentation` — say what an issue is about rather than who fixes it, and appear -on either side: #43 is `product` and `scenario`, because the API fix is elsewhere -and the scenario it suggests is ours. +list.** `product` is a fact about Hookdeck, its docs or its skills, and the fix +is almost always in another repository. `harness` is ours — runner, scorers, +provisioner, seeds and CI — and can be picked up in this repo. The other labels +— `scenario`, `publishing`, `documentation` — say what an issue is about rather +than who fixes it, so either of the two can carry any of them: #43 is `product` +and `scenario`, because the API fix is elsewhere and the scenario it suggests is +ours. + +The label says where the fix goes, not where the finding came from. Most of +these came out of a run, and #43 opens by saying that none did — it came out of +building a demo — and carries `product` anyway, because what a reader filtering +the board wants is the work that is not ours. The two are otherwise indistinguishable on a board and have opposite next actions: a `product` issue needs filing elsewhere and then measuring, a `harness` issue needs a pull request here. `product` was called `finding` until 21 -September and carried both: three of its eleven issues were defects in our own -instrument and moved to `harness`. That is the same conflation the release notes -rule against, where an open defect in our instrument is neither a product finding -nor something shipped. +September and carried both. Of the eleven issues it held, five were measurements +of our own instrument rather than of Hookdeck; three of those moved to `harness` +and the other two are the exception below. That is the same conflation the +release notes rule against, where an open defect in our instrument is neither a +product finding nor something shipped. **A `product` issue carries an `Owned by:` line at the top of its body**, naming the repository and the title the issue would take there: @@ -212,6 +218,16 @@ them, as #34 does — documentation in `hookdeck/outpost`, behaviour in the line rather than guessing: an issue filed against the wrong repository is worse than one not filed. Replace the line with a link once the issue exists. +**Two shapes carry `product` with no `Owned by:` line, and both have their next +step here.** An open question about our own skills or docs does not know its +repository until it has an answer: #2 asks why our skills make the weak model +worse, and where that lands depends on what the runs say. A mapping issue is the +other — its change has already merged elsewhere and it is waiting on a run to +measure it, so it opens with a link to that change, which is what an `Owned by:` +line becomes once the issue exists; #27 links the merged `hookdeck/agent-skills` +pull request in its first line. Anything else carrying `product` with no line is +drift. + A `product` issue is closed by the release that measures the change, not the one that ships it — the mapping-issue rule under Releases — so one sitting open after its fix merged elsewhere is in the correct state. From 4eee3fe373a01b9756e830718ef8b5bf58f973a3 Mon Sep 17 00:00:00 2001 From: Phil Leggetter Date: Tue, 22 Sep 2026 09:26:17 +0100 Subject: [PATCH 3/3] Drop the closed issue from the no-owner examples #2 was closed as its premise: the weak model is not worse with skills on any run since 13 August, and the live half of the question is now #61 and #83. It was one of the two worked examples for a `product` issue with no `Owned by:` line, so the paragraph now describes that shape without citing it and keeps #27, which is still open and still waiting on a run. Co-Authored-By: Claude Opus 5 (1M context) --- AGENTS.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 7bfd346..9afc84f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -199,10 +199,10 @@ The two are otherwise indistinguishable on a board and have opposite next actions: a `product` issue needs filing elsewhere and then measuring, a `harness` issue needs a pull request here. `product` was called `finding` until 21 September and carried both. Of the eleven issues it held, five were measurements -of our own instrument rather than of Hookdeck; three of those moved to `harness` -and the other two are the exception below. That is the same conflation the -release notes rule against, where an open defect in our instrument is neither a -product finding nor something shipped. +of our own instrument rather than of Hookdeck, and three of those moved to +`harness`. That is the same conflation the release notes rule against, where an +open defect in our instrument is neither a product finding nor something +shipped. **A `product` issue carries an `Owned by:` line at the top of its body**, naming the repository and the title the issue would take there: @@ -218,15 +218,15 @@ them, as #34 does — documentation in `hookdeck/outpost`, behaviour in the line rather than guessing: an issue filed against the wrong repository is worse than one not filed. Replace the line with a link once the issue exists. -**Two shapes carry `product` with no `Owned by:` line, and both have their next -step here.** An open question about our own skills or docs does not know its -repository until it has an answer: #2 asks why our skills make the weak model -worse, and where that lands depends on what the runs say. A mapping issue is the -other — its change has already merged elsewhere and it is waiting on a run to -measure it, so it opens with a link to that change, which is what an `Owned by:` -line becomes once the issue exists; #27 links the merged `hookdeck/agent-skills` -pull request in its first line. Anything else carrying `product` with no line is -drift. +**Two shapes carry `product` with no `Owned by:` line**, and both have their next +step here rather than elsewhere. A mapping issue is one: its change has already +merged elsewhere and it is waiting on a run to measure it, so it opens with a link +to that change, which is what an `Owned by:` line becomes once the issue exists — +#27 links the merged `hookdeck/agent-skills` pull request in its first line. An +open question about our own skills or docs is the other: it cannot name a +repository until it has an answer, because the answer is what decides whether the +fix is a skill, a docs page or a scenario. Anything else carrying `product` with +no line is drift. A `product` issue is closed by the release that measures the change, not the one that ships it — the mapping-issue rule under Releases — so one sitting open after