finding-protocol

Finding Protocol — Operational Tier

The operational tier captures the minimum information another agent (or the orchestrator) needs to make a decision. It is not the report deliverable — the deliverable is generated at engagement end by the orchestrator from operational findings + attack-path narrative (see skills/decepticon/final-report/SKILL.md).

File Naming Convention

findings/FIND-{NNN}.md

The file name and the id field in YAML frontmatter (FIND-001, FIND-002, ...) use the same canonical cross-reference. Determine the next ID by counting existing files: ls findings/*.md | wc -l.

Do not create empty scaffold directories or placeholder files before there is a real artifact to write.

Operational Template

Every operational finding uses this minimal Markdown structure with YAML frontmatter — required fields only:

---
id: FIND-001
severity: critical
title: <one-line summary>
cwe: CWE-89               # optional at operational tier; REQUIRED at deliverable promotion
vrt: server-side-injection/sql-injection/blind   # optional Bugcrowd VRT path (category/sub-category/variant)
agent: recon | exploit | postexploit | analyst | ...
objective_id: OBJ-001
discovered_at: "2026-04-06T14:23:11Z"
evidence_pointer: findings/evidence/FIND-001_<slug>.txt
location: http:https://app.example.com/admin/users  # optional but recommended stable locator
---

## Description
2-4 sentences: what the issue is and where.

## Evidence
- <pointer 1>: <one-line per pointer>
- <pointer 2>: <one-line per pointer>


## Verification
Required before a finding is marked confirmed:
- status: `confirmed` or `rejected`
- positive command and discriminating success signal
- equivalent negative-control command and expected baseline signal
- `findings/evidence/FIND-001_verification.json` from `validate_workspace_finding`
- CVSS vector string when confirmed

## Next
next agent should: <action>
OR
blocking — <reason>

The ## Next section is the decision-support hook — the orchestrator reads it to choose the next dispatch.