traverse-framework / traverse-framework/registry
Publish capability: core.content-policy-gate (allow/deny/revise gate for agent output)
- Dominant language
- Rust
- Stars
- 1
- Forks
- 1
- Avg merge
- 1h 17m
- Merged PRs (30d)
- 217
Description
## Why
Agent output should not ship to users/tools without a **content policy gate**. The capability decides `allow` / `deny` / `revise` from structured policy rules (blocked terms, required disclosures, max length, PII-ish patterns) — agent proposes text, runtime enforces.
## One-PR ask
Publish **`core.content-policy-gate@1.0.0`**:
**Inputs:**
- `content`: string
- `policy`: `{ "version": string, "max_length"?: integer, "deny_substrings"?: string[], "deny_regexes"?: string[], "require_substrings"?: string[], "revise_hints"?: string[] }`
- `channel?`: string (trace only)
**Outputs:**
- `decision`: `allow` | `deny` | `revise`
- `reason_codes`: string[] (stable enums you define)
- `policy_version`: string
- `suggested_revision?`: string | null (only when decision=revise; deterministic transform — e.g. truncate + append disclosure — **not** LLM rewrite)
- `ok`: boolean
**Behavior:** Deterministic evaluation order documented (e.g. deny > revise > allow). Invalid policy → deny/fail closed. `revise` must use explicit deterministic transforms only (truncate to max_length, append required disclosure). No silent LLM invent.
Follow [`CONTRIBUTING.md`](https://github.com/traverse-framework/registry/blob/main/CONTRIBUTING.md) and [`capabilities/README.md`](https://github.com/traverse-framework/registry/blob/main/capabilities/README.md) publish checklist.
- Include `capability-src/` with real Rust tests meeting registry coverage gates (`functions` 100%, lines/regions ≥ 95%)
- Use `traverse-cli capability publish` (or the documented scaffold) so `artifact.digest` / `artifact.url` survive
- Declare `authoring.method` (`human` or `llm-assisted`)
- Ensure every `use_cases[].persona_ref` resolves (scaffold personas if needed)
- Run `bash scripts/ci/pre_pr_check.sh ` before opening
- One capability per PR; branch from `origin/main`, not another `publish/*` branch
**Apps are not ready — publish the capability only.** No app wiring, no demo product surface.
## Out of scope
- LLM-based rewriting or toxicity classifiers as a thin wrapper
- Multimodal / image policy
- Persisting moderation queues
## Done when
- CI green; published in next index
- Tests: allow, deny substring, deny regex, revise truncate, invalid policy fail closed
## Host / deps notes
**Pure WASM.** No model, no network, no connector.
## Labels
`help wanted` · `good first issue` · `enhancement` · `no-spec-needed`
Contributor guide
Research direction
Start with CONTRIBUTING.md and capabilities/README.md, then use the documented scaffold or traverse-cli capability publish flow to create capability-src. Add Rust tests for allow, deny, revise, and invalid-policy cases, and run bash scripts/ci/pre_pr_check.sh . Done means the capability is published, CI is green, and the next index includes it without app wiring.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, wasm
- Domain
- backend-api-design, devtools
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100