gate-17: three 'pass-through' methods all have callers, and one carries an _rbac:false policy the detector strips

[rubenvdlinde]

gate-17 redundant-controller reports 3 pass-through methods on hermiq. All three have real callers, and for one of them the detector strips the very argument that makes it not a pass-through. Filing rather than deleting working code.

Measured on development @ cd23f547, run 31490144919; reproduced locally against ConductionNL/.github@main.

lib/Service/AgentTemplateService.php:157 method=get     rule=pass-through-to-ObjectService
lib/Service/AgentTemplateService.php:235 method=delete  rule=pass-through-to-ObjectService
lib/Service/BudgetService.php:659        method=delete  rule=pass-through-to-ObjectService

The gate's premise does not hold here

detect-redundant-controllers.py documents its rationale as ADR-022: the frontend already reaches OpenRegister CRUD directly via useObjectStore, so a per-schema wrapper "ships dead code — observed on decidesk#60: 260 lines with zero callers from the frontend."

Callers exist for all three:

lib/Controller/AgentTemplateController.php:179   $this->templateService->get(templateId: $id)
lib/Controller/AgentTemplateController.php:270   $this->templateService->delete(templateId: $id)
lib/Service/AgentTemplateService.php:208,301,394,454   $this->get(templateId: $templateId)
lib/Controller/BudgetController.php:279          $this->budgetService->delete(budgetId: $budgetId)

AgentTemplateController is a guarded endpoint gating through ActionAuthService::requireAction('agenttemplate.approve-quarantined') per ADR-023 — a check the generic OpenRegister object-patch path does not express. So the frontend does not reach this through useObjectStore, and deleting these methods would inline objectService->find(...) plus the REGISTER_SLUG / TEMPLATE_SCHEMA constants into six call sites.

BudgetService::delete() is not a pass-through at all

public function delete(string $budgetId): void
{
    $this->objectService->deleteObject(
        uuid: $budgetId,
        register: self::REGISTER_SLUG,
        schema: self::BUDGET_SCHEMA,
        _rbac: false,
        _multitenancy: false
    );
}

_rbac: false, _multitenancy: false is a deliberate policy decision, paired with BudgetController::destroy() performing its own organisation-ownership check via mayAdminister() immediately before the call. The detector reduces the body to "one call to a canonical ObjectService method" and never looks at the arguments, so a deliberate RBAC bypass and a plain CRUD wrapper are indistinguishable to it.

That one is worth a second look regardless of this gate: it is the shape most worth keeping in ONE place rather than inlining into a controller.

Suggested gate change (ConductionNL/.github)

A body whose single ObjectService call passes _rbac: false or _multitenancy: false is asserting something about authorisation and should not be classified as a pure pass-through — rule 3 already excludes methods with an authorisation branch, and this is the same claim expressed as an argument rather than an if.

Not done, on purpose

No baseline, no exclude, and no deletion of methods that have callers. gate-17 stays at 3 on hermiq.

[rubenvdlinde]

Re-measured on development @ ce6e1e5, 2026-08-13, ConductionNL/.github@923f57d, full scope: gate-17 still reports the same 3. Every claim in this issue reproduces, and the caller lists are larger than recorded.

⚠️ Line numbers have drifted since this issue was written (AgentTemplateService 157→154 / 235→229, BudgetService 659→642); the methods are the same.

method	verdict
AgentTemplateService::get (:154)	REACHED — 6 callers, and the gate cannot see 4 of them
AgentTemplateService::delete (:229)	REACHED VIA ROUTE, no frontend caller
BudgetService::delete (:642)	REACHED end-to-end, UI → route → controller → service

The four callers this issue did not list are the interesting ones

AgentTemplateService::get has four intra-class callers — :202 (update), :291 (exportTemplate), :381 (approveQuarantined), :440 (instantiate) — plus AgentTemplateController.php:189 (show) and AgentTemplateController.php:735, which is requireTemplateOwnership() itself, called from :245 and :280.

So the method this gate wants deleted is load-bearing for the app's own authorization check on template writes. That is a stronger version of the argument already in this issue, and it is worth stating in those terms because "it is a pass-through" is true — the body really is a bare objectService->find(id:, register:, schema:) with no auth, mapping, validation or event. The gate reads the body correctly and draws the wrong conclusion from it.

Frontend paths that transitively execute it: AgentTemplateRowActions.vue:104-108 → api/agentTemplates.js:107/132/146 → controller exportPackage/approve/instantiate; AgentTemplatePublishModal.vue:62 → api/agentTemplates.js:206 → publishGithub (:674 exportTemplate, :700 update).

AgentTemplateService::delete — a partial concession to the gate

Its only production caller is AgentTemplateController.php:285 (destroy), routed at appinfo/routes.php:402. The frontend never calls it: api/agentTemplates.js:84 exports deleteAgentTemplate and grep over all of src/ finds no import of it (nor of getAgentTemplate, updateAgentTemplate, createAgentTemplate, listAgentTemplates). The Store page is type: "index" over register: hermiq / schema: agenttemplate (src/manifest.json:659-706), so listing and any generic row delete already go through OpenRegister's /apps/openregister/api/objects — exactly the ADR-022 situation gate-17 exists to flag.

But the controller is still not redundant: destroy() adds the 401 check (:277) and requireTemplateOwnership() (:280), which the generic OR object-delete path does not express. The gate names the service method; the thing that would be genuinely redundant is neither.

BudgetService::delete — the _rbac: false point, sharpened

Full chain, every link present: src/views/TenantOps.vue:232 imports deleteBudget, call site :550 → src/api/budgets.js:91-92 → appinfo/routes.php:269 budget#destroy → BudgetController.php:272.

Because the service passes _rbac: false, _multitenancy: false, the controller's guard — 401 (:258), findById→404 (:261-264), mayAdminister()→403 (:267-269) — is the only authorization on this delete. ⚠️ So anyone acting on this gate finding by collapsing the controller into the service, or by exposing the service from anywhere else, deletes the authorization. That is worth a comment at the call site regardless of what the gate does.

Nothing changed. gate-17 stays at 3. The suggested .github rule — a single ObjectService call passing _rbac: false / _multitenancy: false is asserting something about authorisation and is not a pure pass-through — still looks right, and BudgetService::delete is a clean fixture for it.