[FLO-3.2] Specify external process transport and provider trust boundaries

[szmyty]

Outcome

Define and prove the provider-neutral external-process boundary that later Aniflow, Optiflow, and Renderflow adapters will share, without importing sibling source or treating provider output as accepted Flow state.

This is the next bounded child of #3 after #23 / merged PR #24. It consumes the extension-contract foundation from #7 / merged PR #8 and advances the suite roadmap in #11.

Current evidence

• Starting main: 979e033409c823b38591b59eca820522efabfa12.
• Default-branch CI run #35094682274 is green on Rust 1.85, stable Rust, and the repository validators.
• Flow already resolves versioned extensions deterministically and validates one caller-injected in-process port.
• Process framing, artifact locators, executable identity, external-process authority, and host-enforcement evidence remain intentionally unspecified and unimplemented.

Scope

Versioned process transport

• Define one closed v1 process-frame contract for Flow requests, provider events, provider results, and cancellation.
• Specify deterministic UTF-8 JSON encoding, bounded framing, direction, ordering, correlation, termination, EOF, partial-frame, duplicate, contradictory-result, and malformed-message behavior.
• Reserve provider stdout for protocol frames and treat stderr as separately bounded operational evidence, never as a structured result.
• Model launch, exit, timeout, cancellation, output-limit, and grace-period observations without claiming that this checkpoint ships a general child-process runner.
• Keep fallback forbidden after invocation begins.

Artifact binding and acceptance

• Define immutable input and candidate-output bindings with content digest, artifact role, media/domain identity, declared-port correlation, and root-relative locator semantics.
• Reject absolute paths, parent traversal, path escape, missing required outputs, undeclared extra outputs, symlinks, kind mismatches, digest conflicts, and conflicting artifact identities.
• Specify file and directory behavior explicitly. Any directory identity must use a documented deterministic manifest rather than ambient filesystem ordering.
• Keep provider-reported outputs untrusted until Flow validates caller-supplied host observations and produces an accepted artifact set.

Integrity and trust

• Define the exact locked package and executable subjects for process execution.
• Keep observed digest agreement, cryptographic verification, publisher identity, and operator trust as distinct evidence.
• Invalidate process execution when the observed executable subject differs from the lock.
• Preserve extension points for future signature and transparency-log evidence without claiming authenticity from a digest comparison.

Authority and isolation

• Separate requested effects, granted permissions, selected trust mode, and host-enforced guarantees.
• Distinguish trusted-but-unconfined execution from an actually enforced sandbox.
• Fail closed when a selected sandboxed profile lacks the guarantees it claims.
• Require explicit allowlists for argv, environment handles, filesystem, network, subprocess, GPU, publication, signing, and telemetry propagation. Do not inherit arbitrary host state.

Failure and evidence boundaries

• Add typed failures for launch, protocol, framing, identity, integrity, authority, timeout, cancellation, stdout/stderr or frame limits, invalid events, invalid results, and invalid artifacts.
• Retain only explicitly safe, bounded, redacted raw evidence.
• Ensure provider success and exit code zero cannot directly create ValidatedExecution.
• Keep telemetry-only context outside deterministic selection, lock, launch identity, artifact identity, and accepted result identity.

Conformance proof and documentation

• Add redistribution-safe, hermetic success and adversarial fixtures.
• Prove deterministic encoding and directory canonicalization where bytes define identity.
• Prove invalid process or artifact evidence cannot produce accepted execution.
• Prove observer and telemetry configuration cannot affect selection, integrity, launch identity, or accepted result identity.
• Update architecture, integration, contract, README, and roadmap evidence without checking off later adapter or durable-run milestones.

Acceptance criteria

• One versioned, bounded process protocol has deterministic encoding and closed request/event/result/cancellation envelopes.
• Frame decoding fails explicitly on malformed JSON, oversized frames, partial frames, unexpected direction/order, duplicate terminal evidence, frames after a terminal result, and EOF before completion.
• stdout/stderr ownership, capture limits, exit/EOF behavior, timeout, cancellation, and grace semantics are documented and represented by typed evidence.
• A process identity must match the resolved extension, locked package/executable subject, invocation, publisher declaration, capability, interface, configuration, and authorization before evidence can be accepted.
• Artifact validation rejects path escape, absolute paths, symlinks, missing/extra outputs, file/directory mismatches, undeclared ports, digest conflicts, and duplicate identities.
• Package digest observation, cryptographic verification, publisher verification, and operator trust remain separate fields and claims.
• Requested permissions, grants, and actually enforced guarantees are independently represented; sandbox claims fail closed when unenforced.
• Provider-reported success, exit zero, or file existence alone cannot construct ValidatedExecution.
• Telemetry/observer configuration is proven non-authoritative and identity-neutral.
• All fixtures are deterministic, hermetic, and safe to redistribute.
• Architecture, integration, contract, README, and roadmap documentation state implemented guarantees and residual non-goals precisely.
• Required validation passes on Rust 1.85, stable Rust, and every repository validator.

Validation

cargo fmt --all -- --check
cargo clippy --all-targets --all-features --locked -- -D warnings
cargo test --all-targets --locked
cargo test --doc --locked
cargo run --example hermetic_extension --locked
cargo package --locked
python3 tools/validate_contracts.py
python3 .agents/specs/validate-specs.py
python3 .agents/skills/validate-skills.py
python3 .agents/agents/validate-agents.py

Non-goals

• A supported public flow run, plan, resume, or doctor CLI.
• A production child-process supervisor or general process-execution library.
• A real Aniflow, Optiflow, or Renderflow adapter.
• Arbitrary dynamic library loading.
• Durable plans, run state, checkpoints, retry, interruption, or resume.
• A general DAG executor.
• Claiming a real OS sandbox where none is enforced and tested.
• A logging backend, OpenTelemetry exporter, hosted vendor, or shared observability crate.
• Cross-repository source imports or mutable Git dependencies.
• Unrelated repository cleanup.

Follow-up

After merge, add one real Aniflow adapter against released or immutable conformance evidence, then reinspect Optiflow for the first read-only adapter.

Roadmap-Step: FLO-Q02

[szmyty]

Implementation inspection confirmed that framing, artifact acceptance, executable verification, and enforceable authority are independently reviewable trust boundaries. I split the first dependency-unlocking slice into #26. This branch/PR will implement #26 only; #25 remains the parent for the later artifact, integrity, authority, and bounded-runner children.

[szmyty]

The first focused child, #26, is implemented in #27. CI run 35133684960 passes on Rust 1.85.0, stable Rust, and all repository validators. This PR remains limited to stdio framing and host-neutral transcript validation; artifact binding, executable/package integrity, authority profiles, and a real process runner remain on this parent.