rohit/probo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Promote tracker patterns to org third parties via worker

Browse Source 
Manual moves of a non-extension TrackerPattern lacking a ThirdPartyID
now request mapping, which the tracker-mapping worker resolves with a
four-stage pipeline: exact common_third_party_id link, heuristic
ranking, agent disambiguation, and finally CreateFromCommon. Existing
fuzzy-matched org rows are tagged with common_third_party_id so the
next promotion takes the O(1) exact-link path.

The matching primitives live in pkg/thirdparty (RankCandidates,
LinkToCommon, CreateFromCommon, ScoredCandidate, threshold constants)
so the disambiguation agent and the heuristic share one candidate
type. Cookiebanner orchestrates them; cookie-banner-specific concerns
(pattern -> common-pattern -> common-party navigation, the EXTENSION
gate, and structured logs) stay in the worker.

Signed-off-by: Émile Ré <emile@probo.com>
This commit is contained in:
Émile Ré
2026-05-28 17:20:36 +02:00
parent 33ddba9770
commit a99a4dde14
12 changed files with 1491 additions and 94 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
contrib/claude/file-naming.md
View File

@@ -42,17 +42,48 @@ pkg/cookiebanner/pattern_analysis_worker.go
## Agent files
When a package has a worker that uses an agent, the agent construction logic
goes in `<worker_prefix>_agent.go` alongside `<worker_prefix>_worker.go`. The
worker file stays focused on `Claim`/`Process` and handler methods; the agent
file owns agent construction, prompt building, constants, config, and the
`//go:embed` directive for prompt templates.
A file whose **sole purpose** is to construct and operate an agent uses the
`<name>_agent.go` suffix. The agent file owns agent construction, prompt
building, the `//go:embed` directive for prompt templates, the typed result,
the agent-specific config, and any agent-only constants (timeout, confidence
threshold). Callers (workers, services) hold a `*agent.Agent` field and import
the file's `Build…Agent` constructor.
This applies in two shapes:
1. **Paired with a worker** (most common). The worker file
`<worker_prefix>_worker.go` stays focused on `Claim`/`Process`, and the
agent it uses lives in `<worker_prefix>_agent.go` next to it.
```
pkg/cookiebanner/tracker_mapping_worker.go -- worker handler
pkg/cookiebanner/tracker_mapping_agent.go -- agent construction + prompts
```
2. **Standalone, called from elsewhere.** When the agent is consumed by a
different package (or by multiple packages — e.g. an agent that operates on
a domain entity, used by several feature workers), it lives in the package
that owns the domain, named `<purpose>_agent.go`.
```
pkg/thirdparty/disambiguation_agent.go -- catalog→org ThirdParty matcher
pkg/vetting/sub_agent.go -- generic vetting sub-agent
```
A file is NOT renamed to `_agent.go` when the agent is incidental to a service
that does substantially more than agent orchestration (e.g. CRUD, caching,
auth). In that case the file keeps its service name and the agent is built
inline:
```
pkg/cookiebanner/tracker_mapping_worker.go -- worker handler
pkg/cookiebanner/tracker_mapping_agent.go -- agent construction + prompts
pkg/evidencedescriber/evidencedescriber.go -- single-file describer service
pkg/vetting/assessment.go -- third-party assessment service
```
If the agent construction grows past a few dozen lines or sprouts its own
prompt embed / typed result / config struct, extract it into a sibling
`<purpose>_agent.go`.
## Tool files
Each agent tool lives in its own `<tool_name>_tool.go` file, named after the