feat(ingest): a container's pinned team decides, as the config always claimed #49
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "pinned-team-decides"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
feat(ingest): a container's pinned team decides, as the config always claimed
The Project type has carried this comment since routing moved into the file:
Only the second sentence was ever implemented.
team:was consumed solely asa routing-table qualifier — "/=repo" disambiguates WHICH REPO a
team's work lands in — while the team itself always came from the assignee
mapping, falling through to PLOEG_DEFAULT_TEAM for anyone unmapped. A config
that pinned a project to
team: approuted nothing to app unless theassignee independently mapped there, which makes the pin a comment about an
intention rather than a control.
The gap has a concrete cost on a real board. On ClickUp, assignees are
licensed workspace members — there are no bot users to invent, and the
validator's one-assignee-one-team rule means a PERSON can only ever trigger a
single tier. The natural gesture — three Lists, one per tier, drop a task in
the right one — was unexpressible.
Now the pin decides. After mirror() has fetched the item (a thin clickup
webhook carries no List, so the scope is only known post-fetch, which is why
this cannot live in a provider), ingest overrides the assignee's team with the
container's pinned team, then resolves the target — so the team-qualified
routing rules see the team the work will actually run as. Unpinned containers
are byte-for-byte unchanged: the assignee still decides.
Config grows ScopeTeams(): every project with both a pinned id and a team.
Name-resolved projects are deliberately absent until a resolver hands their
ids back — the shape that needs pinning is the shape that pins ids.
Gates: gofmt clean, go vet clean, go build ok, go test ./... ok, goldens
untouched (no chart change).
Driving consumer: code14's staging cluster, routing three ClickUp Lists to the docs/app/infra tiers. Without this, tier selection on a board with licensed seats has no workable gesture.
The Project type has carried this comment since routing moved into the file: Team routes this project's work to one team. Empty means the assignee decides, via the team's `assignees` list below. Only the second sentence was ever implemented. `team:` was consumed solely as a routing-table qualifier — "<scope>/<team>=repo" disambiguates WHICH REPO a team's work lands in — while the team itself always came from the assignee mapping, falling through to PLOEG_DEFAULT_TEAM for anyone unmapped. A config that pinned a project to `team: app` routed nothing to app unless the assignee independently mapped there, which makes the pin a comment about an intention rather than a control. The gap has a concrete cost on a real board. On ClickUp, assignees are licensed workspace members — there are no bot users to invent, and the validator's one-assignee-one-team rule means a PERSON can only ever trigger a single tier. The natural gesture — three Lists, one per tier, drop a task in the right one — was unexpressible. Now the pin decides. After mirror() has fetched the item (a thin clickup webhook carries no List, so the scope is only known post-fetch, which is why this cannot live in a provider), ingest overrides the assignee's team with the container's pinned team, then resolves the target — so the team-qualified routing rules see the team the work will actually run as. Unpinned containers are byte-for-byte unchanged: the assignee still decides. Config grows ScopeTeams(): every project with both a pinned id and a team. Name-resolved projects are deliberately absent until a resolver hands their ids back — the shape that needs pinning is the shape that pins ids. Gates: gofmt clean, go vet clean, go build ok, go test ./... ok, goldens untouched (no chart change).