Get Issue Extraction
issues
Get Issue Extraction
Stored 5C extraction for one issue — READ-ONLY over stored state,
NEVER a live LLM call.
Wire contract (pinned by the platform frontend — do not deviate)::
{ "issue_id": "iss_x",
"fields": { "concern": {"value": str|null, "origin": str|null},
"cause": {...}, "context": {...}, "consequence": {...},
"correction": {...} } }
Field -> stored `issues` column mapping (FIVE_C_COLUMNS,
app/engine/forge/extract.py — shared with the extraction-stats endpoint):
concern <- issues.concern (C1)
cause <- issues.cause (C4)
context <- issues.context (C2, migration 0026)
consequence <- issues.consequence (C3)
correction <- issues.cap (C5 "Corrective Action Plan",
migration 0026)
written by forge_issue -> repo.apply_canonical_5c (top-level columns,
NOT structured_attrs).
Origin semantics (honesty rule): these five columns are written ONLY by
the extraction path today, and `issues.attr_origins` (0045 provenance,
human-wins) does not cover them — 5C-column provenance is not yet wired,
so human corrections currently cannot exist for these fields (known
follow-up, out of scope here). The wire contract's origin union keeps
"human"/"heuristic" for forward-compat, but this endpoint emits ONLY
"extracted" (value stored) or null (no value) — emitting anything else
would fabricate provenance.
Errors: unknown/deleted/cross-workspace issue -> 404 `not_found`; issue
exists but no non-empty 5C value stored (never forged, or fully
abstained) -> 404 `not_extracted` with details {"reason": "no extraction
stored"} (two distinct codes, same convention as assignment-lineage).
GET
Get Issue Extraction
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Response
Successful Response
The response is of type Response Get Issue Extraction V1 Issues Issue Id Extraction Get · object.