Skip to content

Research: define the external-mutation safety envelope #8

Description

@joaomj

Parent map: #1

Decision to resolve

What safety promise can TinyHarness honestly make when it denies detected mutations outside the active project using its native tools and hooks?

Product requirement

Detected external mutations are denied by default and cannot be approved around. Native approval behavior remains for other actions. Initial operation uses hooks/policy rather than an OS sandbox.

Questions

  • Which native tools expose exact target paths and can enforce the rule reliably?
  • Which shell constructs and indirect side effects cannot be determined statically?
  • How should ambiguous commands behave?
  • How do symlinks, traversal, subprocesses, environment variables, and git commands affect the promise?
  • Which hook failures must fail closed?
  • What adversarial regression corpus is needed?
  • Which operations must remain unavailable for unattended use until OS confinement exists?

Output

A threat model, explicit guarantee/non-guarantee statement, and recommended user-visible policy behavior.

Resolves when

The map can state a testable safety contract without claiming sandbox guarantees hooks cannot provide.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

researchPrimary-source investigation that resolves a decisionwayfinderDecision map and wayfinding work

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions