Skip to content

Align firewall boundary with weaver-spec (Frames-only ingestion) #144

@dgenio

Description

@dgenio

The Problem

contextweaver currently stores raw outputs via apply_firewall and ArtifactStore. This is a direct boundary conflict with weaver-spec BOUNDARIES.md, which states:

agent-kernel owns: raw tool output → firewall → Frame + Handle + access control + audit log.

contextweaver ingests only: Frame (safe view). It never receives raw tool output by default.

And Invariant I-05:

contextweaver's ingestion interface accepts Frame objects. An implementation of contextweaver that accepts raw tool output as a first-class input is not spec-compliant.

If left unresolved, this boundary violation will fracture the ecosystem — downstream adopters won't know which component is responsible for firewalling, leading to either duplication or gaps.

Decision to Implement (per spec)

Keep contextweaver's core as context + routing only. Move any "raw output firewall/artifact storage" into one of:

  • (a) An optional integration module ("execution layer") — clearly separated from core context compilation, explicitly documented as non-canonical
  • (b) Defer fully to agent-kernel — remove firewall/artifact storage code from contextweaver entirely and document the canonical integration path

Acceptance Criteria

  • Docs updated so the canonical path is: contextweaver consumes Frame events only
  • Any raw-output handling is clearly marked "optional / non-canonical" (if keeping option (a))
  • apply_firewall and ArtifactStore are either:
    • Moved to an optional/ or integrations/ module with clear warnings, OR
    • Removed entirely with a migration note
  • One integration example: agent-kernel → Frame → contextweaver event log
  • README and architecture docs reflect the corrected boundary

Priority

P0 — This is the only issue that can silently fracture the ecosystem if left unresolved.

References

Metadata

Metadata

Assignees

No one assigned

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions