feat: add draft data, gap analysis report, and workspace config

workspace/drafts/agent-context-policy/master-prompt-ietf-id.md

@@ -0,0 +1,98 @@
+# Master Prompt: Minimal IETF I-D for Agent DAG Token + HITL Policy
+
+You are an expert IETF editor and protocol designer.
+
+Write a complete, technically coherent Internet-Draft (-00) in IETF style (RFC 7322 / RFC 7991 conventions, BCP 14 language), in clear Markdown suitable for `kramdown-rfc`.
+
+## Objective
+
+Create a **minimal base specification** for safe agent context transfer with exactly two core contributions:
+
+1. **Agent DAG Token**: a lightweight token container that models agent/task delegation as a DAG.
+2. **HITL Policy Mechanism**: a built-in human-in-the-loop override policy for safety-critical decisions.
+
+The draft should be inspired by:
+
+- draft-nennemann-wimse-ect-00 (concept lineage)
+- draft-richer-wimse-token-container-00 (base token container idea)
+
+But this new draft MUST:
+
+- **NOT require encryption overhead** in the base spec.
+- **NOT depend on broader WIMSE framework components**.
+- stay **small, sharp, and implementation-friendly**.
+- focus on **safety first**, not regulated-environment complexity.
+
+## Design Constraints
+
+- Keep the draft intentionally narrow and deployable.
+- Base profile only; define extension points for future work.
+- Do not include advanced compliance features in the core.
+- Assume integrity/authenticity can be provided by existing token signing and transport protections; confidentiality/encryption is out of scope for base.
+- Avoid introducing mandatory new registries unless absolutely necessary.
+
+## Required Content
+
+Produce a full I-D with these sections:
+
+1. Title, Abstract, Status, Copyright
+2. Introduction (problem statement and why safety needs DAG + HITL)
+3. Conventions and Terminology (BCP14 + terms)
+4. Use Cases (2–3 concise safety-centric examples)
+5. Requirements (minimal normative requirements)
+6. Token Model
+   - Minimal claims set (base claims + DAG claims)
+   - DAG representation (nodes, edges, constraints)
+   - Processing semantics (validation, traversal, delegation checks)
+7. HITL Policy Model
+   - Policy object structure (trigger, required human role, action)
+   - Runtime behavior (pause/escalate/override/abort/continue)
+   - Audit event requirements (minimal decision record)
+8. Interoperability and Deployment Considerations
+9. Security Considerations
+   - Safety failure modes
+   - Abuse/misuse
+   - Why confidentiality is out of scope in base
+10. Privacy Considerations (minimal but explicit)
+11. IANA Considerations (likely none, or minimal if truly needed)
+12. References (normative + informative)
+13. Appendix A: Compact JSON examples
+
+- one DAG token example
+- one HITL policy example
+- one end-to-end processing example
+
+## Token/Profile Specific Guidance
+
+- Keep token structure aligned with a generic token container philosophy.
+- Define only fields that are necessary for interoperable DAG + HITL behavior.
+- Separate:
+  - **Token data model** (what is carried)
+  - **Processing rules** (how recipients act)
+- Include clear error handling outcomes for:
+  - invalid DAG
+  - missing node context
+  - policy trigger without reachable human approver
+  - conflicting policy actions
+- Include a strict “Out of Scope” subsection listing:
+  - encryption envelope
+  - regulated controls
+  - remote attestation
+  - trust framework onboarding
+  - rich workflow orchestration
+
+## Style and Quality Bar
+
+- Be concise and normative where needed.
+- Avoid hand-wavy text; include precise behavior.
+- Keep -00 realistic: minimal yet complete.
+- Prefer clarity over completeness.
+- Include TODO markers only where absolutely unavoidable.
+
+## Output Format
+
+Return:
+
+1. **Suggested draft name** (`draft-<author>-<topic>-00`)
+2. **Final full draft Markdown**
+3. **A one-page delta note**: “What this base draft intentionally does NOT include yet (and why)”