# PDR 000: Own severe vulnerability remediation through production validation

- HTML version: https://robbiepalmer.me/projects/agent-coordinator/pdrs/000-severe-vulnerability-resolution
- Project: Agent Coordinator
- Status: Accepted
- Opened: 2026-10-30
- Decided: 2026-10-30

## Context

GitHub can identify a vulnerable dependency, and Renovate can propose a version
change. Neither owns the result when the update needs application changes, the
proposal fails CI, the repository has no matching Renovate pull request, or the
merged change must be deployed and checked.

The original Agent Coordinator concept started with general allocation of ready
Work Graph tickets. Recent T3 Code support for signed webhook automations and
agent-directed top-level thread launch makes that workflow available through a
controller session without a separate allocation product. General ticket fan-out
therefore provides weak evidence that Agent Coordinator adds value.

Severe vulnerability remediation has a clear trigger, meaningful risk, existing
deterministic automation to build on, and an observable end state. It tests
whether agent intelligence can close the gap between a machine-generated signal
and a healthy deployed system.

## Decision

Make severe dependency vulnerability resolution the first Agent Coordinator
product workflow.

For an admitted GitHub Dependabot alert, the product will inspect the current
alert and any related Renovate pull request. It will use an existing proposal
when that is the safest path, repair or replace it when necessary, or create a
new fix when no useful proposal exists. The owning agent remains responsible
through required checks, review, merge, deployment, production validation, and
recovery from a failed rollout.

The initial personal-project policy permits agents to merge and operate the
established deployment path without routine human approval. Repository checks
and branch protection remain in force. Agents may not suppress the alert,
weaken those controls, or treat a merged pull request as proof that the deployed
risk is resolved.

The product asks for attention when it lacks required authority, cannot choose
a safe outcome from available evidence, or exhausts its bounded recovery policy.
The request must name the decision or access it needs and preserve the work
already completed.

Renovate remains the deterministic dependency-update system. Agent Coordinator
does not reproduce package discovery, update scheduling, or ordinary version
proposal generation.

## Consequences

The first release has a narrow outcome that exercises the complete coordination
loop. Success requires more than generating code or opening a pull request. It
requires a fix that reaches the deployed system and passes the project's stated
validation.

The workflow grants agents meaningful write, merge, and operational authority.
An incorrect change can break a personal service. Recovery and revert behaviour
therefore belong to the first product boundary even though the current projects
have no external users.

Some alerts will have no safe immediate fix. The product must represent that
truth rather than forcing a dependency update or dismissing the alert. These
cases still produce useful evidence about missing authority, incompatible
dependencies, absent rollout contracts, or gaps in repository context.

General Work Graph allocation moves out of the initial product scope. T3 Code
controller sessions can still query ready work and launch threads for it, but
that convenience does not justify a separate first release.

## Evaluation

Evaluate every admitted alert against the full outcome record:

* Did the controller avoid launching duplicate work?
* Did it correctly use, replace, or decline the available Renovate proposal?
* Did the accepted change pass repository checks without weakening them?
* Did the intended deployment receive the merged revision?
* Did project-specific validation pass after deployment?
* When work failed, did the system recover, revert, or request the precise help
  it needed?
* Did the Dependabot alert close, or did the record explain why closure still
  lagged or could not occur?

Review unnecessary launches, human interventions, elapsed time, model cost, and
rework after real incidents. Expand to other engineering signals only when this
loop produces trustworthy outcomes.

## Related records

- Project: [Agent Coordinator](https://robbiepalmer.me/projects/agent-coordinator.md)
- Implemented by ADR: [ADR 001: Use T3 Code as the orchestration control plane](https://robbiepalmer.me/projects/agent-coordinator/adrs/001-t3-code-orchestration-control-plane.md)
- Implemented by ADR: [ADR 002: Write incident state from events instead of polling for work](https://robbiepalmer.me/projects/agent-coordinator/adrs/002-event-driven-incident-ledger.md)

---

Markdown index of this site: https://robbiepalmer.me/llms.txt