bug: genie dir add --global silently fails to register agent in PG

[namastex888]

Description

genie dir add <name> --dir <path> --global appears to succeed but doesn't persist the agent entry to the PG agents table. Subsequent directory.resolve() calls fail with "Agent not found in genie directory".

Reproduction

genie dir add felipe-scout --dir /home/genie/workspace/agents/felipe/agents/felipe-scout --global
# Output: "Agent registered (global)"

genie dir ls felipe-scout --json
# Output: "Agent not found in directory or built-ins"

Root Cause

The agent directory is now PG-backed (agent-directory.ts). The add() function inserts into the agents table with id = 'dir:<name>'. However, when --global is passed, the _options?: ScopeOptions parameter with { global: true } is accepted but never used — the function always does the same PG insert regardless of scope.

The issue may be that:

1. The PG connection fails silently during add (no error thrown)
2. The --global flag triggers a different code path that doesn't persist
3. The insert succeeds but the query in resolve() doesn't find it

Impact

• Omni bridge cannot resolve agents registered with --global
• Non-owner WhatsApp messages fail to route to their assigned agent
• Agent spawn fails with "Agent not found in genie directory"

Workaround

Register without --global:

genie dir add felipe-scout --dir /home/genie/workspace/agents/felipe/agents/felipe-scout

🤖 Generated with Claude Code

[namastex888]

Trace + twin-review findings (not a simple unused-param bug)

A deeper trace revealed this is an architectural gap, not a bug in add():

Real root cause: The PG agents table has no scope column. Evidence:

• agent-directory.ts:138 — INSERT INTO agents (id, role, custom_name, started_at, metadata) VALUES (${'dir:' + entry.name}, ...) — the id encodes only the name, not a scope.
• agent-directory.ts:153 — DELETE FROM agents WHERE id = ${'dir:' + name} — no scope filter.
• agent-directory.ts:248 — ls() hard-codes scope: 'global' on every returned entry regardless of how it was registered.

So genie dir add foo --global and genie dir add foo (no flag) target the same row. The CLI layer plumbs { global: true } correctly into add()/rm()/get(), but the storage layer has no way to distinguish project from global. The _options?: ScopeOptions parameter is unused because there is nothing meaningful to do with it at the current schema.

Decision needed (before any code change)

Pick one:

1. Actually implement scope. Add a scope column (or composite key dir:<scope>:<name>) via a PG migration. Update add/rm/resolve/ls/edit to filter by scope. Migrate existing rows to global.

2. Remove the --global flag and the false "Agent registered (global)" messaging. Keep the single-scope behavior and document that there is only one directory.

Either direction is a product decision. Option 1 is a non-trivial change (schema migration + ~5 function updates + tests). Option 2 is a ~20-line revert.

This has been deferred from the autonomous overnight queue until the direction is chosen.