Document Curator Incident

Document curator incident

Turn post links into a sourced curator incident under eth_defi/data/feeds/curators/{curator-slug}.yaml.

Input

Require one or more post links. Ask for replacement links only when none of the supplied pages or indexed copies provide enough evidence to identify the curator and describe the incident without guessing.

Step 1: Read and verify the posts

Open every supplied link and record:

• The author and publication date
• The curator named or clearly implicated
• The underlying event, impact, and current resolution status
• The specifically affected vault addresses and protocol slugs
• Whether statements are first-party facts, a post-mortem, or third-party claims

When a social site blocks direct access, use indexed search results or another public copy of the same post. Do not treat an inaccessible page as evidence and do not turn an unverified allegation into a statement of fact. Attribute disputed or third-party claims in the incident description.

Use the publication date of the primary, most authoritative post as the incident date in YYYY-MM-DD format. If an authoritative source states a distinct event date, prefer the event date. When merging, retain the existing date unless the new evidence establishes a more accurate one.

Step 2: Identify the curator YAML

Search existing curator metadata before editing:

rg -n -i "{curator name}|{curator handle}" eth_defi/data/feeds/curators eth_defi/vault/curator.py

Match the organisation that managed or curated the affected vault. Do not assign the incident to a protocol, asset issuer, quoted commentator, or reposting account merely because it appears in a post. If more than one existing curator is plausible, stop and ask the user which curator is intended.

If no curator YAML exists, use the add-curator skill first. Do not create an incomplete curator record as part of this workflow.

Step 3: Decide whether to add or merge

Read the curator's existing incidents list in full.

• Merge when a record describes the same underlying event, even when the title, post date, or source URL differs.
• Treat an overlapping link as definitive evidence that the record already exists.
• Add a new record when the posts concern a separate event.
• If the supplied links cover multiple unrelated events, create or merge one record per event rather than combining them.

When merging, append only new links, preserve useful existing evidence, and revise the title, description, date, label, or severity only when the new sources justify the change. Merge newly confirmed vault addresses and protocols into their existing lists without removing previously sourced context.

Step 4: Classify and write the incident

Use this YAML shape:

incidents:
  - date: YYYY-MM-DD
    links:
      - https://example.com/primary-source
      - https://example.com/additional-source
    vault_addresses:
      - 0x1234567890abcdef1234567890abcdef12345678
    protocols:
      - lagoon-finance
    title: Concise incident title
    description: |
      Write three to five factual Markdown sentences with [inline source links](https://example.com/primary-source).
      Attribute claims and use [additional sources](https://example.com/additional-source) where they support the body text.
    incident_kind: misleading
    severity: other

Write a neutral title and a three-to-five-sentence Markdown description. Every description paragraph must contain at least one inline Markdown link. Prefer links embedded on the claim they support; do not use bare URLs or a separate sources list inside the description. Avoid promotional language, investment advice, and facts not supported by the supplied posts.

Choose exactly one incident_kind:

• collapse: the curator or its managed operation failed broadly, became insolvent, or ceased functioning
• significant_loss: investors suffered a material loss without a full collapse
• minor_loss: losses were limited in scope or impact
• misleading: accounting, valuation, performance, or public disclosures were materially misleading
• questionable_behaviour: substantiated governance, conflict, or conduct concerns that fit none of the labels above

Use the incident's main nature as the label. Do not invent numerical loss thresholds. Also set the schema-required severity to collapse, significant_loss, minor_loss, or other based on demonstrated impact. A misleading or questionable_behaviour incident normally has severity other unless sources demonstrate a loss or collapse.

Do not change risk.status merely because an incident is added. Risk review is a separate decision unless the user explicitly requests it.

Step 5: Update context lists and validate

Store all supplied links that support the incident in links, preserving the primary source first and removing exact duplicates. Links must use HTTP(S).

Fill vault_addresses with only the vaults demonstrated to be affected by the sources. Resolve named vaults through repository metadata or the public vault page, and lowercase EVM addresses. Include downstream vaults when a source explicitly documents contagion through a position in the directly affected vault, but do not add every vault managed by the curator. Fill protocols with the canonical protocol slugs used by repository vault metadata. Both lists must be non-empty. If an affected address or protocol cannot be verified, stop and ask the user for the missing context rather than guessing.

Validate the edited curator through the shared strict YAML schema:

CURATOR_YAML=eth_defi/data/feeds/curators/{curator-slug}.yaml poetry run python - <<'PY'
import os
from pathlib import Path

from eth_defi.feed.sources import load_feeder_metadata

path = Path(os.environ["CURATOR_YAML"])
metadata = load_feeder_metadata(path)
assert metadata.get("incidents"), path
print(path)
PY

Then run:

git diff --check

Report the curator, whether the incident was added or merged, the selected date, incident_kind, severity, and the number of links, vault addresses, and protocols now attached to the record.