Add docs/issues.md with prioritized, ready-to-paste GitHub issue drafts

[Copilot]

The issue requested creating GitHub issues from the prior roadmap outline, but direct issue creation is not supported in this environment. This change adds a repository-native, copy-paste issue pack so the 11 proposed items can be created quickly and consistently.

• Scope

  • Added a single documentation artifact: docs/issues.md.
  • Captures all 11 recommended issues from the provided outline (P0/P1/P2 set).

• Content structure

  • Each issue includes:
    • Title
    • Body
    • Why
    • Acceptance Criteria
  • Wording is normalized for direct paste into GitHub Issues without additional editing.

• Outcome

  • Converts the chat-proposed backlog into an actionable issue inventory in-repo, preserving prioritization and implementation criteria.

## 4) Semantic provider hardening (timeouts, retries, circuit breaker, fail-open/closed per tool)

**Title**
`Harden semantic provider with retries, circuit breaker, and per-tool fail mode`

**Body**
### Why
Infra teams require predictable behavior during provider outages.

### Acceptance Criteria
- Configurable per-tool behavior when semantic provider fails
- Clear config: `semantic_rules.mode = off|enforce|advisory`
- Circuit breaker after N failures

Original prompt

I can outline the issues, but I can’t create GitHub issues with the tools available here (I can read repos/PRs/files, and I can write files/branches; issue creation isn’t supported). If you want, I can generate ready-to-paste issue titles + bodies and you can bulk create them, or I can write them into docs/roadmap.md in the repo.

Also, your repo currently shows 1 open item, but it’s a pull request (“intent guard” #1), not an issue.

Below are independent issues I recommend (prioritized for PMF with code agents now, while building the path to platform later).

---

P0 (PMF blockers for AI-infra adoption with code agents)

1) Add a stable “decision contract” (codes, severity, policy metadata, override info)

Why: infra needs machine-readable enforcement + analytics, not just allowed/reason.
Acceptance:

• GuardDecision includes: decision_id, code, severity, policy_name, policy_version, rule_id, timestamp
• Support override fields when approved (who/why/ttl)

2) Add OpenTelemetry + metrics (latency, allow/block, approval, provider errors)

Why: makes it operable and measurable → adoption becomes safe.
Acceptance:

• OTEL spans around each tools/call evaluation
• Prometheus/OTEL metrics: intent_guard_decisions_total{allowed,code,tool}, intent_guard_eval_latency_ms, intent_guard_provider_errors_total

3) Replace terminal approval with pluggable non-interactive approval backends

Why: terminal prompt doesn’t scale beyond a dev laptop.
Acceptance:

• Approval interface supports: webhook callback, timeout, default action
• “break-glass token” option (env var / signed token) for CI

4) Semantic provider hardening (timeouts, retries, circuit breaker, fail-open/closed per tool)

Why: infra will not accept unpredictable outages.
Acceptance:

• Configurable per-tool behavior when semantic provider fails
• Clear config: semantic_rules.mode = off|enforce|advisory
• Circuit breaker after N failures

5) Policy validation + “policy compiler”

Why: YAML needs schema validation + deterministic normalization.
Acceptance:

• intent-guard policy validate schema/policy.yaml
• Fails on unknown keys/types; prints helpful errors
• Emits normalized compiled policy JSON (optional)

---

P1 (makes it “necessary” across dev orgs)

6) First-class “resource mapping” for tools (explicit arg mapping, not path heuristics)

Why: to enforce safely you must know what the tool is touching.
Acceptance:

• Policy can define per-tool argument mapping, e.g. path_arg: params.arguments.path
• Resource types: filesystem.path, repo.branch, etc.

7) Policy templates for code agents (ready-to-run packs)

Why: fastest path to organic dev adoption.
Acceptance:

• policies/ with templates: code-agent-safe.yaml, repo-write-guard.yaml
• Docs: “pick one, change 3 lines”

8) “Advisory mode” with reporting-only (no blocking)

Why: lets teams deploy without fear → gather PMF data.
Acceptance:

• Proxy passes through but logs would_block=true
• Summary report CLI: top violations, risky tools, protected path hits

---

P2 (bridge to enterprise platform component)

9) Central policy distribution mechanism (minimal control plane v0)

Why: infra wants one policy standard, not per-repo YAML sprawl.
Acceptance:

• Load policy from: local file OR HTTPS URL OR S3/GCS (pick one first)
• Policy signature verification (at least HMAC or public key) to prevent tampering
• Support policy version pinning

10) HTTP gateway mode (in addition to MCP stdio proxy)

Why: enterprise platform will want a network-deployable component.
Acceptance:

• Run as a service that receives tool-call evaluation requests
• Can be used by embedded SDKs

11) Audit log format + export sinks

Why: enterprise adoption requires auditability.
Acceptance:

• JSON log schema documented (fields stable)
• Optional sinks: file, stdout, webhook, OTEL log exporter

---

Quick next step

If you confirm you want these as (A) a docs/issues.md file with copy-paste bodies or (B) a docs/roadmap.md committed to the repo, tell me which—and I can use githubwrite to add it to main or dev.

Also tell me your preference for policy distribution v0:

• Git-based (policy in repo + signed tag), or
• HTTP URL (fetch + signature), or
• S3 (common for infra teams).

create the GitHub issues as outlined in that chat above.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[temp-noob]

@copilot can you create separate issues for all the items highlighted?

[Copilot]

@copilot can you create separate issues for all the items highlighted?

I can’t directly create GitHub issues from this environment (issue-creation API/action isn’t available to me). I’ve already prepared all 11 as separate, ready-to-paste issue drafts in docs/issues.md (commit db32d4c) so they can be bulk-created quickly in the repo UI. If you want, I can also reformat them into a CSV/import-friendly structure in a follow-up commit.