Skip to content

Arachne Feature Request Template (Privacy‑First)

Owner: GhostWeasel (Lead: doubletap-dave)

Purpose: Propose improvements that align with Arachne’s goals—composability, predictability, observability, and privacy.

1) Summary

2) Motivation and Use Cases

  • Primary use case(s):
  • Pain points with current behavior:
  • Expected outcome/value:

3) Proposed Behavior / API

  • Runtime/Library API (conceptual):
  • Example types/functions/classes (names and purpose only)
  • CLI (if applicable):
  • Subcommands, flags, and expected outputs
  • Configuration (if applicable):
  • Keys, defaults, and validation rules

4) Scope and Non‑Goals

  • In scope:
  • Out of scope:

5) Alternatives Considered

  • Alternative A:
  • Pros:
  • Cons:
  • Alternative B:
  • Pros:
  • Cons:

6) Impact

  • Backward compatibility:
  • Performance considerations:
  • Observability implications (logs/metrics/traces):
  • Privacy posture (no payloads in errors by default; redaction hooks):
  • Operational complexity:

7) Milestone Fit

  • Suggested horizon (v1.x / v2.x / v3.x+):
  • Related roadmap items or Decision Records (if any):

8) Acceptance Criteria (EARS‑style)

  • Ubiquitous: “The system shall …”
  • Event‑driven: “When , the system shall …”
  • State‑driven: “While , the system shall …”
  • Unwanted: “If , the system shall …”

Example: - The system shall provide a CLI subcommand arachne diagnostics collect that creates a redacted bundle by default. - When a user runs the command, the CLI shall omit secrets and payload contents and include environment summaries. - While running under minimal permissions, the CLI shall degrade gracefully and indicate missing non‑essential data. - If redaction fails for any field, the system shall default to omission rather than inclusion.

9) Example (Conceptual, Sanitized)

  • User flow: 1) … 2) … 3) …
  • Expected structured logs (redacted values; stable keys):
  • event="feature_event", component="...", status="success"

10) Risks and Mitigations

  • Risk:
  • Mitigation:
  • Risk:
  • Mitigation:

11) Testing and Documentation Plan

  • Tests:
  • Unit:
  • Integration:
  • Regression/compatibility:
  • Documentation:
  • README changes:
  • docs/plan or Decision Record:
  • Examples/recipes:

12) Dependencies and Compatibility

  • New dependencies (runtime vs dev):
  • Compatibility with Python 3.11+:
  • Adapter requirements (optional/plug‑in):

13) Open Questions

  • Q1:
  • Q2:

14) Checklist (Submitter)

  • No payload contents, PII, secrets, or tokens included
  • Clear problem statement and target users
  • Proposed behavior and non‑goals documented
  • EARS‑style acceptance criteria provided
  • Privacy and observability implications considered
  • Testing and docs plan sketched

References

  • Governance and Overview (M0): docs/plan/M0-governance-and-overview.md
  • Post‑v1 Roadmap: docs/plan/post-v1-roadmap.md
  • Contributing Guide: docs/contributing/CONTRIBUTING.md
  • Troubleshooting: docs/support/TROUBLESHOOTING.md
  • How to Report Issues: docs/support/HOW-TO-REPORT-ISSUES.md