feat(dir): add manager-scoped agent discovery via pluggable org resolver

[vivekkrishna]

Summary

Closes #1445

Introduces manager-scoped agent discovery: given a manager alias, find all agent records owned by anyone in their org subtree. Ownership is expressed via the owner.id annotation on records; the org hierarchy is provided by a pluggable org.Resolver.

• New --manager flag on the search command expands a manager alias to their full subtree (direct + indirect reports) and returns all records whose owner.id annotation matches any alias in that set
• Pluggable org.Resolver interface (server/org/resolver.go) with a static YAML file backend as the first implementation
• Optional by design — if org_resolver is absent from the config the server starts normally; --manager returns an informative error. All other search is unaffected.
• RECORD_QUERY_TYPE_MANAGER = 16 added to proto (regenerated pb.go)
• Dedicated SQL JOIN alias (owner_ann) for the owner filter, so --manager and --annotation can be combined without interference
• E2e tests (13_manager_search_test.go) cover subtree expansion, leaf nodes, aliases outside the org chart, unknown aliases, and combined --manager + --annotation filtering

Configuration

server:
  org_resolver:
    type: "static"
    static:
      file: "org-chart.yaml"   # relative to config file directory, or absolute

Org chart format (YAML)

[email protected]:
  - [email protected]
  - [email protected]
[email protected]:
  - [email protected]

Usage

# Find all agents owned by alice or anyone in her org subtree
dirctl search --manager [email protected]

Design decisions — feedback welcome

1. owner.id annotation convention: we rely on records being tagged with owner.id: <alias> to express ownership. This is a convention, not enforced by schema validation today. Should this be a first-class field, or is annotation-based ownership the right model?

2. Proto enum vs server-side handling: RECORD_QUERY_TYPE_MANAGER is a new proto enum value. An alternative would be to handle --manager purely in the CLI by pre-expanding aliases before sending queries. The current approach keeps expansion server-side (where the org chart lives), which feels cleaner but does touch the wire format.

3. Static-only resolver for now: the org.Resolver interface is designed to support LDAP, IdP, or Git-based team resolvers in the future, but only the static YAML backend is implemented here. Happy to drop the interface and ship a concrete type if the team prefers not merging an abstraction without a second implementation.

Test plan

• go build ./... — server, CLI, e2e tests
• go vet — server, CLI
• All server unit tests pass
• task gen — no uncommitted diffs after regeneration
• task lint (golangci-lint via pre-commit hook) — passes
• E2e annotation tests (12) — 10/10 pass (regression)
• E2e manager tests (13) — 6/6 pass
• E2e full suite — 190/191 pass (1 pre-existing failure in signature test unrelated to this change)

[codecov]

Codecov Report

❌ Patch coverage is 53.18352% with 125 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
reconciler/tasks/ownership/task.go	0.0%	45 Missing ⚠️
server/controller/store.go	31.8%	11 Missing and 4 partials ⚠️
cli/cmd/ownership/ownership.go	58.6%	6 Missing and 6 partials ⚠️
reconciler/service/service.go	0.0%	8 Missing and 1 partial ⚠️
api/ownership/v1/claim.go	61.9%	4 Missing and 4 partials ⚠️
server/controller/search.go	77.1%	4 Missing and 4 partials ⚠️
server/database/gorm/record.go	75.9%	6 Missing and 1 partial ⚠️
server/org/static/resolver.go	68.4%	3 Missing and 3 partials ⚠️
server/server.go	44.4%	3 Missing and 2 partials ⚠️
reconciler/tasks/ownership/config.go	0.0%	4 Missing ⚠️
... and 4 more

📢 Thoughts on this report? Let us know!

[ramizpolic]

Hi @vivekkrishna, thank you for contributing. I do agree that ownership is something that needs to be addressed, but I am not sure if this is the approach we would want to take. There are two important things that I would like to adjust here:

• Rather than doing ownership claims through annotations, we can patch OASF with dedicated fields to make it more explicit
• Local discovery vs network discovery is not addressed here and only impacts local discovery

For this PR to go forward, I would suggest we start from an issue/discussion and agree on a plan collectively as this is an important feature. We do support right now ownership through DNS/HTTPs claims through record naming (e.g. my-agent vs https://microsoft.com/agents/my-agent/v1.0.0 but we have no way to aggregate these locally or on the network.

[vivekkrishna]

Hi @ramizpolic , that makes sense, should we use this thread to discuss and finalize on the approach? #1468 ?

[ramizpolic]

Yes, lets continue the discussion there. If you are available today (5th of May) at 5PM CEST, we have a public community meeting. This would be an interesting topic to discuss

[vivekkrishna]

I can attend with a proposal, can you share the meeting link?

[ramizpolic]

I can attend with a proposal, can you share the meeting link?

@vivekkrishna here is the google calendar link https://zoom-lfx.platform.linuxfoundation.org/meetings/agntcy?view=week