RFC: define Digital Job Pack v0.1 from three real roles

## Decision to make Define the minimum portable contract for a reusable digital role that can execute through compatible CHG adapters without hiding permissions, approvals, evidence, or provider-specific requirements. P0 does **not** have a stable Digital Job Pack contract. This issue is the public design record. ## Evidence before schema Propose at least three materially different roles, for example: 1. repository release-readiness reviewer; 2. source-backed market or policy researcher; 3. bounded customer-support triage operator. Each role must identify purpose/non-goals, typed inputs and outputs, required harness capabilities, tool/network/filesystem permissions, approval points, artifacts, evaluation fixtures, failure rules, supported contract version, maintainer, and licenses. ## Questions - Which fields belong in a portable manifest versus a harness adapter or deployment policy? - How are capabilities declared and rejected before a run starts? - How are prompts, scripts, fixtures, and evaluation rules packaged and versioned? - How do we bind outputs and evidence to Job, Run, Session, Project, and Trace identity? - What can be MIT-licensed, and what content or trademarks need separate treatment? - What conformance tests must every Job Pack pass? ## Exit criteria - [ ] Three concrete role proposals reviewed publicly. - [ ] Draft schema and lifecycle mapping. - [ ] Threat model covering permission escalation, prompt injection, credential leakage, and misleading evidence. - [ ] Packaging and versioning rule. - [ ] License and trademark boundary. - [ ] Reference Job Pack plus conformance fixtures. - [ ] Maintainer approval before the contract is called stable. Use the [Digital Job Pack proposal form](https://github.com/ericjbe/cogiens-harness-gateway/issues/new?template=digital-job-pack.yml) for each concrete role and link it here.