Say where a tooling defect goes when the loop is a guest in another repo (#290)

[fdaviddpt]

Closes #290.

What changed

Two documents, one gap. skills/manager/SKILL.md and agents/developer.md both argued hard for filing a dependency defect upstream, and both were silent on the case that actually comes up when this plugin is installed somewhere: the loop is a guest in somebody else's project, and the defect is in the tooling rather than in their code.

Both now say it plainly, and say it as encouragement rather than as permission: a defect in the rule layers written into their tree, in an owned file, in the brief, in an op the brief mandates, in the launcher or in the diagnostic goes to the tooling's tracker. Never to the host project's, whose maintainer did not write it, cannot patch it, and in most cases cannot see it declared anywhere — so a report there reads as work done while the board that could ship the fix never hears.

The reverse is stated with equal weight, because a rule that only pushes one way invites the opposite mistake: the host project's own code stays the host project's. The split is who owns the code, never who is standing closest.

The measurement behind it

declared_dependencies():   ['supertool', 'remember', 'claude-jit-context']
dependency_repositories(): supertool          -> .../claude-supertool
                           remember           -> .../claude-remember
                           claude-jit-context -> .../claude-jit-context
is claude-oss itself in that list? False

declared_dependencies() reads the manifest at PLUGIN_ROOT, so this resolves from any repository the loop is pointed at — the machinery already works in a guest repo, which is not what I assumed when I filed #290. The correction is on the issue.

What it cannot produce is one name: the loop's own repository, because nothing declares itself as its own dependency. That is exactly the board that owns the furniture written into a managed repo. Both documents now say to read an absent name as not derivable, never as no tracker.

The instance

A first pass of this loop over a repository that installed the plugin filed fifteen issues. Fourteen are genuine findings in that project, correctly placed and well evidenced. One reported that a contributor without supertool has every file operation blocked with no fallback — a defect in a rule that ships from supertool and is enforced in every repository, filed on a board with no route to a fix. It is now filed upstream where it can land.

Review status — read this before merging

This diff was written by the maintainer, not by a developer agent, at the maintainer's own instruction and against this repository's own rule that the manager does not write the diff. So the independent read that every other pull request here gets does not exist for this one. It is prose only — no product code, no test logic — and tests/test_content_invariants.py plus tests/test_developer_brief_duties.py pass (135 passed), which is the weakest of the available evidence and is stated as such.

It is deliberately not merged. A reviewer should decide whether the new section earns its length in a file #245 is already open about, and whether the guest-repo case belongs in the manager skill, the developer brief, or only one of them.

[fdaviddpt]

Correction to this pull request's justification

The body above says the guest-repo case was silent in both documents and implies that silence caused a misrouted report. The first half is true. The second half is not supported.

claude-supertool#1789 was filed by a downstream maintainer's loop, from the downstream repo, straight onto the tooling's tracker — with a reproduction, the failing op, the succeeding retry, and the collapsing function named by line. No wording in this diff existed when that happened.

So this change is a clarity improvement, not a fix for an observed failure. The section still earns its place — a rule that only works when the reader gets it right unaided is a rule waiting to be got wrong — but a reviewer should weigh it as prose competing for space in a file #245 is already open about, not as a defect being closed.

The measurement that motivated it stands unchanged and is the durable half: the loop's own repository is the one board dependency_repositories() cannot name.

[fdaviddpt]

Reviewed. Holding this rather than merging, and the reason is new since the body was written.

The blocker

This diff tells both documents to read an absent name as not derivable, never as no tracker. That is correct today. PR #304 is open right now and makes the name derivable — #292's loop_repository() resolves the loop's own repository off the repository key at PLUGIN_ROOT, the same key dependency_repositories() already reads for every other plugin, and /oss:doctor reports it.

So merging this first ships guidance describing a gap that closes one pull request later. Two individually correct commits composing into a document that is wrong about its own tooling — the class this repository is named after, and the one no per-diff review catches.

The measurement in the body stays true and is the durable half. What changes is the instruction built on it: after #304 the sentence is not the name is not derivable but call loop_repository(), and read its three states — resolved, read-and-does-not-say, could-not-read. That third state is the one this diff's reasoning was protecting, and it survives; it just has a mechanism now instead of a caution.

The two questions the body asked a reviewer to settle

Does the section earn its length? Partly, and less than when it was written. The body's own correction comment already withdrew the motivating instance — claude-supertool#1789 was filed correctly from a guest repo with none of this wording present. Against #245, which is open about SKILL.md being 1027 lines paid unconditionally every tick, 44 lines of prose that fix no observed failure is a weak trade. Rewritten against loop_repository() it gets stronger, because it would then be documenting a call rather than a caution.

Manager skill, developer brief, or one of them? One. The developer brief is where it belongs: the developer is the agent that hits a tooling defect mid-task and has to route it, and it already carries the dependency-reporting section this extends. The manager reads report-for-filing items and files them; it does not need the routing rule restated, and SKILL.md is the file under length pressure.

Also worth knowing

This branch and fix/300 (#301) both edit agents/developer.md and skills/manager/SKILL.md. Whichever merges second needs a re-merge and a fresh run regardless, so nothing is lost by this one going second — or third, after #304.

Not closing it. The guest-repo gap is real and the reverse rule — the host project's own code stays the host project's; the split is who owns the code, never who is standing closest — is the sentence worth keeping whatever else changes.