safety(intake): issue bodies as artifact input put untrusted text upstream of the adversarial cascade

If the factory starts taking content from GitHub issues, issue bodies become spec input, and issue bodies are written by anyone with an account. That is a trust boundary the pipeline does not currently have anywhere else, because until now every artifact input came from an agent the orchestrator dispatched.

This is the safety half of the flow proposed in #510 and spun out of #833. #510 proposes that external artifact content arrives as a linked issue for the factory to crystallize. That shape is right, and it is also the first time untrusted text reaches the spec layer.

## What makes issue content different from every other input

Existing inputs are produced by specialists the orchestrator dispatched, under prompts the project controls, and validated by hooks that assume well-formed agent output. An issue body is none of those. Three specific properties:

1. **It is attacker-influenceable text.** Anyone can open an issue. If crystallization is even semi-automatic, the content flows into BC bodies, story specs, or error tables. A BC is a normative document that later agents treat as authority, so a poisoned BC is a durable instruction to every future agent on the project, not a one-off bad input.
2. **It arrives without provenance by default.** #510 proposes ArcavenAE issues carry a signed-branch reference for exactly this reason. That convention protects content from one known source; it says nothing about the general case, and a project that grows a habit of ingesting issues will eventually ingest one from a stranger.
3. **It has no schema.** Every other artifact has a template and a hook that validates it. Prose in an issue has neither, so the validation burden falls on whichever agent transcribes it.

## The failure shape worth naming

The dangerous case is not obvious junk, which review catches. It is plausible, well-formatted content that is subtly wrong: an EC row with an inverted condition, an error code that collides with an existing one, a postcondition that relaxes a guarantee. That is the class the adversarial cascade exists to catch in the project's own output, and it would be entering *upstream* of the cascade, wearing the shape of a spec rather than of a proposal.

## Shapes worth considering

- **A quarantine kind.** External content lands as a distinct artifact kind (proposal, not spec) that no agent may cite as authority, and only a human-approved crystallization promotes it. The BEDROCK/FRONTIER distinction already models this; external input starts at neither.
- **Never auto-apply.** #510 already suggests external content pass human review or the adversarial stage before crystallizing. Worth making that a hard rule rather than expected posture, because the whole value of the flow is throughput and throughput is exactly the pressure that erodes a soft rule.
- **Transcription, not ingestion.** A specialist reads the issue and authors the artifact in the project's own voice and template, rather than the issue text becoming the artifact. Slower, and it puts a schema-aware agent between untrusted prose and the spec layer.
- **Provenance as a gate, not a note.** If an issue carries a signed-branch reference, verify it and record the verification; if it does not, route to a different, slower path. That makes #510's provenance convention load-bearing rather than advisory.
- **Treat issue text as data in every prompt that handles it.** The agents that triage external issues should be told the content is untrusted input and not instructions, the same way any tool handling third-party content needs to be.

## Ask

If the artifact-as-issue flow in #510 goes ahead, would you want external content to land as a non-citable proposal kind that a human promotes, rather than being crystallized directly into a BC or story? Happy to draft the triage checklist if the shape is agreed.

Review the flow proposed in issue #510 and the adversarial cascade design. Understand the artifact kinds (like BCs) and the existing validation hooks. The goal is to design a safety mechanism for untrusted input, not to implement a specific code change. Start by reading the linked issues to grasp the context.

Scritto dal modello di indicizzazione a partire dal testo della issue.