Skip to main content

Integrations

Documentation Map​

Integrations

Scope​

This document lists real implemented Integration contracts first and planned minimal follow-ups second. It follows the shared Helpifyr Integration documentation standard without introducing a new runtime model.

10/10 Truth Boundary​

ConcernOwner of recordWarp posture
Identity / human & agent registry / ownership intent / access intentjhf-spindleconsumer only
Runtime orchestration / runtime state / drift / rollout / reconcilejhf-warpowner
Projection / composition / integration contextjhf-fabricconsumer only
Messaging / delivery / topology-sensitive transportjhf-shuttleconsumer/provider of versioned event payloads, not transport owner
Environment/runtime capability exportjhf-openclaw-envconsumer only
Install / upgrade executionjhf-deploymentconsumer only
Auth truth / OIDC / token issuancejhf-heddleconsumer only
Normative governance / approvals / policy authorityjhf-spineplanned consumer only
Secret authority / secret scope / rotation / invalidationjhf-keystoreconsumer of references or leases only

Conflict policy:

  • owner-of-record wins
  • stale copies must not widen privilege
  • mutating lanes fail closed on conflicting upstream truth

10/10 Delegation / Revocation Projection​

Warp now persists a local runtime-side delegation projection in explicit tables and exposes it read-only through:

  • /api/v1/agent-runtime/delegations
  • /api/v1/agent-runtime/delegation-state
  • /api/v1/agent-runtime/readiness

Current posture:

  • local grants are backfilled idempotently from persisted sub-agent lifecycle
  • local trust defaults to restricted
  • downstream invalidation remains fail-closed
  • secret-backed delegation rights depend on Keystore-issued references or leases

Agent Federation Runtime Contract​

Warp now exposes the deterministic agent-federation read contract needed by Heddle/Fabric for Wave 3/4:

  • /api/v1/agent-runtime/catalog
  • /api/v1/agent-runtime/catalog/{agent_id}
  • /api/v1/agent-runtime/delegations
  • /api/v1/agent-runtime/delegation-state
  • /api/v1/agent-runtime/readiness
  • /api/v1/events/contracts/current

Current posture:

  • root revoke and descendant invalidation are explicit and replay-safe
  • provisioning-class changes are never inferred from absence or naming alone
  • agent.catalog.changed, agent.delegation.changed, agent.execution.spawned, and agent.execution.retired are the canonical federation event families
  • ambiguous parentage, multiple roots, degraded-root fallback, and zombie lockout are surfaced as explicit fail-closed markers
  • Fabric can project these states directly without local Heddle heuristics

This projection does not replace Heddle auth truth, Fabric projection ownership, or Keystore secret authority. It exists so those consumers can read deterministic runtime/delegation truth from Warp instead of reconstructing it locally.

10/10 Desired-State / Reconcile Projection​

Warp now persists a local desired-state and bounded reconcile projection in explicit tables and exposes it through:

  • /api/v1/reconcile/desired-state/current
  • /api/v1/reconcile/ledger
  • /api/v1/reconcile/run

Current posture:

  • desired-state baseline is backfilled from current managed runtime, delegation, tenancy, and runtime-classification state
  • reconcile lanes are explicit: observe-only, propose-only, approved-bounded-apply
  • bounded apply remains fail-closed when runtime inventory is unavailable, scope truth conflicts, or expected control-agent presence is missing
  • anti-flap posture uses persisted cooldown, suppression, retry budget, and read-back hash

This projection does not replace Spindle ownership truth, Heddle auth truth, Fabric projection semantics, future Spine governance truth, or Keystore secret authority.

10/10 Tenancy / Isolation Projection​

Warp now persists a local fail-closed runtime-side scope projection in tenancy_scope_records.

Current posture:

  • active runtime scope: scope:team:warp-runtime
  • scoped read surfaces expose scope_context
  • external-org lanes remain blocked for cross-scope communication and elevated actions by default
  • local baseline records are backfilled idempotently and tagged record_origin=warp-tenancy-baseline

This projection does not replace upstream truth from Spindle, Fabric, Heddle, or Keystore.

10/10 Install / Topology Class Boundary​

Warp now publishes a local runtime classification for:

  • install class
  • topology class
  • supportability

This classification is deliberately bounded:

  • it is valid for Warp readiness, release, and reconcile posture
  • it must not be treated as local bundle truth
  • Fabric and Deployment remain owner-of-record for combination/install truth beyond Warp's own runtime posture

Current reference:

  • docs/INSTALL_TOPOLOGY_SUPPORTABILITY.md

10/10 Eventing / Failure-Domain Projection​

Warp now exposes a local read-only projection for canonical eventing and degraded evidence:

  • /api/v1/events/contracts/current
  • /api/v1/events/outbox/current
  • /api/v1/events/degraded/evidence

Current posture:

  • the event model is versioned but transport-agnostic
  • persisted outbox state is local Warp truth for delivery evidence, not transport ownership truth
  • degraded evidence stays explicit and recoverable by domain_key
  • stale or conflicting upstream authority must fail closed
  • compensation posture is explicit for reconcile, downstream delivery, and support-action classes

This projection does not replace Shuttle transport ownership, Heddle auth truth, or Keystore secret authority.

10/10 Security / Approval Projection​

Warp now exposes a local read-only projection for the M7 security baseline:

  • /api/v1/security/approval/current
  • /api/v1/security/regression-matrix
  • /api/v1/security/emergency-controls/current

and one bounded local control surface:

  • POST /api/v1/security/emergency-controls/apply

Current posture:

  • approval explainability is explicit per action class
  • emergency controls remain local Warp runtime state, not Fabric or Heddle truth
  • secret-backed actions fail closed when emergency posture or upstream authority is degraded
  • support mutation and approved bounded reconcile now block before execution when emergency stop or scope freeze is active

10/10 Release / Migration Projection​

  • Warp publishes its current release-readiness evidence locally and consumes integrated upstream truth read-only.
  • The current M8 release baseline is anchored by:
    • docs/UPGRADE_MIGRATION_GUIDE_10_10.md
    • docs/E2E_LIVE_VERIFICATION_MATRIX_2026-04-12.md
    • docs/RELEASE_CANDIDATE_EVIDENCE_PACK_2026-04-12.md
    • docs/POST_RELEASE_OBSERVATION_ROLLBACK_PLAYBOOK.md
  • install/topology, policy, identity, OIDC, and secret truth remain upstream-owned even during release verification.

Internal Helpifyr Integrations​

openclaw-runtime​

  • Direction: outgoing
  • Type: execution-contract
  • Surface: openclaw CLI, runtime inventory, topology diff, patch planning, apply preparation, openclaw.json
  • Auth: host/runtime access configuration
  • Stability: stable
  • Versioning: OpenClaw runtime shape plus local compatibility fixtures; no separate API version contract
  • Owner: jhf-warp-maintainer

Read-latency posture:

  • SSH-backed read-only visibility paths use a shorter bounded discovery timeout so cold inventory, topology, and metrics reads degrade quickly instead of burning the full retry budget
  • refresh and mutation-oriented runtime reads keep the fuller retry posture used by execution and reconciliation paths

doubtfire-control​

  • Direction: incoming
  • Type: execution-contract
  • Surface: POST /api/v1/control-agent/runtime/apply, POST /api/v1/control-agent/reconcile, GET /api/v1/control-agent/status, related lease/watchdog/schedule surfaces
  • Auth: Bearer token plus projected authority context and deployment-time/gateway boundary
  • Stability: stable
  • Versioning: API path versioned under /api/v1; cycle-id semantics documented in control-agent docs
  • Owner: jhf-warp-maintainer

Operating policy:

  • runtime install/reconcile is operator-triggered through POST /api/v1/control-agent/runtime/apply
  • deployment and packaging do not auto-reconcile Doubtfire by default
  • any future auto-reconcile mode would need an explicit feature flag and a documented contract change

jhf-pattern​

  • Direction: outgoing
  • Type: product-adapter
  • Surface: POST /api/v1/jhf-pattern/setup-request
  • Auth: base URL plus auth token
  • Stability: stable
  • Versioning: local API path versioned under /api/v1; downstream contract version not negotiated by this repo
  • Owner: jhf-warp-maintainer

jhf-spindle​

  • Direction: outgoing
  • Type: product-adapter
  • Surface: POST /api/v1/jhf-spindle/setup-request
  • Auth: base URL plus auth token
  • Stability: stable
  • Versioning: local API path versioned under /api/v1; downstream contract version not negotiated by this repo
  • Owner: jhf-warp-maintainer

Support-agent consumer boundary:

  • Warp consumes Spindle-owned Zammad support contracts as read-only owner truth
  • delegated support-agent context for Spindle/Zammad is documented in docs/SPINDLE_SUPPORT_AGENT_ACCESS.md
  • caller ID is not an auth factor; service-token handling remains Spindle-owned runtime configuration

Persistent-agent registration consumer boundary:

  • the downstream contract is documented in docs/SPINDLE_AGENT_REGISTRATION_REQUEST_CONTRACT.md
  • any future Warp persistent-agent create or adopt flow must require a Spindle-backed business record linkage before local materialization
  • required linkage includes stable business identity, sponsor linkage, tenant/company/team boundary, explicit team_scope_key, lifecycle intent, registration class, and registry status
  • direct access-right assignment is explicitly out of scope for this contract and must stay upstream-owned or policy-projected elsewhere
  • direct downstream provisioning is explicitly out of scope for this contract and must stay upstream-owned or policy-projected elsewhere
  • tool/action execution posture is now consumed read-only through Warp ACP-W2 policy truth:
    • GET /api/v1/agent-tool-policies
    • fabric-manifest.json -> compatibility.agent_tool_policy_projection
  • validator coverage exists today through validate_persistent_agent_registration_request(...) and scripts/verify_spindle_agent_registration_contract.py
  • implementation of a dedicated Warp create endpoint remains deferred; this is a versioned contract definition plus executable validation, not a shipped runtime route

jhf-shuttle​

  • Direction: outgoing
  • Type: product-adapter
  • Surface: POST /api/v1/integrations/jhf-shuttle/topology-sync, sync history/current read surfaces
  • Auth: base URL plus auth token
  • Stability: stable
  • Versioning: local API path versioned under /api/v1; downstream contract version not negotiated by this repo
  • Owner: jhf-warp-maintainer

External Integrations​

postgres​

  • Direction: outgoing
  • Type: database-contract
  • Surface: JHF_WARP_DB_DSN, Alembic-owned schema under alembic/
  • Auth: DSN credentials
  • Stability: stable
  • Versioning: Alembic migration lineage plus SQLAlchemy/psycopg compatibility; no public DB version API
  • Owner: jhf-warp-maintainer

gitea-actions​

  • Direction: incoming
  • Type: operator-consumer
  • Surface: .gitea/workflows/ci.yml, shared Linux runner execution
  • Auth: runner context
  • Stability: stable
  • Versioning: workflow file on main; no external versioned CI API contract
  • Owner: jhf-warp-maintainer

gitea-packages​

  • Direction: outgoing
  • Type: repository-intake
  • Surface: scripts/oci_image.sh, workflow publish path, <internal-runtime-redacted>:3000/jaddahelpifyr/jhf-warp:<tag>
  • Auth: GITEA_PACKAGES_TOKEN
  • Stability: stable
  • Versioning: explicit OCI tags sha-<12>, branch tag such as main, optional channel tags
  • Owner: jhf-warp-maintainer

docker-oci-tooling​

  • Direction: outgoing
  • Type: execution-contract
  • Surface: image build, local container run, deployment references
  • Auth: host/runner tooling
  • Stability: stable
  • Versioning: container image tags plus Docker/OCI tooling compatibility; no repo-local API version
  • Owner: jhf-warp-maintainer

fabric-manifest-self-description​

  • Direction: outgoing read-only
  • Type: repo-read
  • Surface: GET /fabric-manifest.json, fabric-manifest.json, GET /ready, GET /version, GET /openapi.json, GET /metrics
  • Auth: self-description routes open; /metrics uses the internal projected-authority boundary
  • Stability: stable
  • Versioning: manifest schema is repo-local and endpoint surface evolves with service version plus /api/v1 API references
  • Owner: jhf-warp-maintainer

Event Contracts​

canonical-event-contract-read-model​

  • Direction: outgoing read-only
  • Type: contract-read
  • Surface:
    • GET /api/v1/events/contracts/current
    • GET /api/v1/events/outbox/current
    • GET /api/v1/events/degraded/evidence
  • Auth: Bearer token plus projected authority context
  • Stability: stable
  • Versioning: local /api/v1 plus event contract version 2026-04-12.jhf-warp-event.v1
  • Owner: jhf-warp-maintainer

Implemented:

  • Warp publishes transport-agnostic event families, clock/replay semantics, failure domains, and compensation posture
  • outbox delivery metadata is persisted and readable
  • degraded evidence is persisted with explicit recovery timestamps

Planned:

  • downstream transport-owner alignment with jhf-shuttle
  • owner-side degraded auth truth from jhf-heddle, projection posture from jhf-fabric, future governance truth from jhf-spine, and secret contracts from jhf-keystore

control-agent-reconcile-callback​

  • Direction: incoming
  • Type: webhook
  • Surface: POST /api/v1/control-agent/reconcile
  • Auth: Bearer token plus projected authority context; no dedicated callback signature. For POST /api/v1/control-agent/reconcile, jhf-warp injects deterministic Doubtfire Fabric-projection headers when the callback uses the canonical write token and those headers are missing (subject, business, session, technical-client, and tenant tuple).
  • Stability: stable
  • Versioning: /api/v1 plus documented reconcile request/response contract
  • Owner: jhf-warp-maintainer

n8n-topology-sync-delivery​

  • Direction: outgoing
  • Type: webhook
  • Surface: POST /api/v1/integrations/jhf-shuttle/topology-sync, persisted sync history/current readback
  • Auth: JHF_WARP_JHF_SHUTTLE_BASE_URL plus JHF_WARP_JHF_SHUTTLE_AUTH_TOKEN
  • Live control-bridge delivery on <internal-runtime-redacted> must use the container-reachable Shuttle target http://jhf-shuttle-n8n:5678/webhook/agent-status-callback; the legacy host-side :5678 publication and the host-loopback <internal-runtime-redacted>:15678 binding are not valid container-side truth
  • Stability: stable
  • Versioning: local /api/v1 contract plus downstream operator endpoint compatibility
  • Owner: jhf-warp-maintainer

jhf-pattern-setup-delivery​

  • Direction: outgoing
  • Type: webhook
  • Surface: POST /api/v1/jhf-pattern/setup-request
  • Auth: JHF_WARP_JHF_PATTERN_BASE_URL plus JHF_WARP_JHF_PATTERN_AUTH_TOKEN
  • Stability: stable
  • Versioning: local /api/v1 contract plus downstream Helpifyr Pattern endpoint compatibility
  • Owner: jhf-warp-maintainer

jhf-spindle-setup-delivery​

  • Direction: outgoing
  • Type: webhook
  • Surface: POST /api/v1/jhf-spindle/setup-request
  • Auth: JHF_WARP_JHF_SPINDLE_BASE_URL plus JHF_WARP_JHF_SPINDLE_AUTH_TOKEN
  • Stability: stable
  • Versioning: local /api/v1 contract plus downstream Helpifyr Spindle endpoint compatibility
  • Owner: jhf-warp-maintainer

MCP Integration​

in-process-mcp-read-tools​

  • Direction: outgoing read-only
  • Type: mcp
  • Surface: src/oc_agent_manager/mcp/read_tools.py
  • Auth: no network auth; Python in-process only
  • Stability: partial
  • Versioning: wraps current API/app contracts; no separate external MCP version
  • Owner: jhf-warp-maintainer

Implemented:

  • read-only MCP wrappers exist as in-process Python modules backed by the local FastAPI app

Planned:

  • no remote MCP server is implemented in the current baseline

in-process-mcp-safe-action-tools​

  • Direction: outgoing
  • Type: mcp
  • Surface: src/oc_agent_manager/mcp/safe_action_tools.py
  • Auth: no network auth; Python in-process only
  • Stability: partial
  • Versioning: wraps current API/app contracts; no separate external MCP version
  • Owner: jhf-warp-maintainer

Implemented:

  • guarded MCP action wrappers exist as in-process Python modules backed by the local FastAPI app

Planned:

  • no remote MCP server is implemented in the current baseline

Planned Connections​

jhf-heddle​

  • Direction: incoming auth/identity consumer
  • Type: identity-consumer
  • Surface: upstream OIDC login and token issuance consumed through clear auth/identity boundaries; no direct local IdP surface in Warp
  • Auth: upstream OIDC / token issuance truth
  • Stability: planned
  • Versioning: no repo-local OIDC schema authority; consumer behavior follows the documented boundary in docs/OIDC_CONSUMER_BOUNDARY.md
  • Owner: jhf-warp-maintainer

Implemented:

  • Warp documents and enforces a consumer-only OIDC posture
  • Warp does not mint, issue, or reinterpret identity claims as a local authority
  • Warp keeps Heddle logically relevant as the auth truth even when Fabric projection is present

Planned:

  • future operator-context enrichment may consume approved OIDC claims
  • no local session authority or shadow IAM model will be introduced in Warp

jhf-fabric​

  • Direction: outgoing read-plus-projection
  • Type: projection-composition
  • Surface: planned reads of GET /fabric-manifest.json, GET /ready, GET /version, GET /api/v1/combinations/profiles, GET /api/v1/contracts/jarvis, GET /api/v1/contracts/jarvis/readiness, GET /api/v1/contracts/registry, GET /api/v1/contracts/families, GET /api/v1/contracts/schemas, GET /api/v1/contracts/matrix, GET /api/v1/contracts/docs-standard, GET /api/v1/identity/contracts, GET /api/v1/events/access-control/contracts, optional projection endpoint for normalized caller/integration context, optional GET /metrics, optional GET /api/v1/runtime/inventory, optional GET /api/v1/drift/summary
  • Auth: same gateway/internal-network policy as the service; optional service-to-service projection auth may be configured
  • Stability: partial-read-only
  • Versioning: Fabric Wave-3 consumer adoption is pinned to [email protected], [email protected], [email protected], [email protected], and [email protected]; JARVIS consumer adoption is pinned read-only to [email protected], [email protected], [email protected], [email protected], [email protected], and [email protected]
  • Owner: jhf-warp-maintainer

Implemented:

  • jhf-warp already exposes read-first artifact inputs through GET /fabric-manifest.json, GET /ready, GET /version, and existing read-only runtime/drift surfaces
  • jhf-warp now consumes Fabric-authored combination truth read-only from GET /api/v1/combinations/profiles
  • jhf-warp now also consumes the Wave-3 Fabric governance truth from:
    • GET /api/v1/contracts/matrix
    • GET /api/v1/contracts/docs-standard
    • GET /api/v1/identity/contracts
    • GET /api/v1/events/access-control/contracts
  • jhf-warp now also consumes the canonical JARVIS adoption/closure truth read-only from:
    • GET /api/v1/contracts/jarvis
    • GET /api/v1/contracts/jarvis/readiness
    • GET /api/v1/contracts/registry
    • GET /api/v1/contracts/families
    • GET /api/v1/contracts/schemas
    • GET /api/v1/contracts/matrix
  • JARVIS lifecycle and closure posture remain Fabric-owned; Warp must not recreate that truth from issue archaeology or repo-local completion markers
  • Fabric may also provide normalized projected context, but this is middleware/projection behavior, not the final governance brain
  • supported Fabric profile keys for this consumer posture are:
    • fabric-warp-shuttle
    • fabric-warp-bobbin
    • fabric-warp-shuttle-bobbin
    • warp-standalone-openclaw
  • current verify path is read-first only
  • Wave-3 live verify path is:
    • python scripts/verify_fabric_wave3_contracts.py --base-url <fabric-base-url>
  • JARVIS live verify path is:
    • python scripts/verify_fabric_jarvis_contracts.py --base-url <fabric-base-url>
  • support-triggered action bundles may also emit optional Fabric case/run event envelopes when a Fabric endpoint is configured
  • the current integrated attachment contract is metadata-first only:
    • naming and lifecycle come from fabric-manifest.json
    • active combination semantics come from Fabric-authored combination truth and are never recomputed locally
    • runtime presence comes from /ready, /version, and optional authenticated internal reads
    • the primary operational Postgres state remains tool-local
    • no shared-service registration callback exists yet
    • standalone posture remains tool-local, but rejoin must validate against the canonical Fabric combination profile before claiming bundle membership

Support-triggered action specifics:

  • POST /api/v1/support/actions/propose
  • POST /api/v1/support/actions/execute
  • every emitted action bundle references case_id, run_id, and approval_id when present
  • Warp remains action truth; Fabric remains run/case/audit truth after event ingestion
  • rollback, partial commit after lost ack, stale approval, human override, and customer-sensitive guardrails are documented in docs/SUPPORT_TRIGGERED_ACTIONS.md

Planned:

  • Fabric may consume the existing read-only surfaces as the smallest pull-first discovery step
  • no registration callback, no new discovery-specific API, and no control-plane write-back are part of the current baseline

jhf-spine​

  • Direction: planned outgoing governance consumer
  • Type: governance-authority
  • Surface: future policy / approval / normative decision contracts; no active Warp integration yet
  • Auth: planned, no current contract
  • Stability: planned
  • Versioning: planned
  • Owner: jhf-warp-maintainer

Implemented:

  • Warp currently keeps future Spine docking explicit in docs and authority terminology
  • Warp must not permanently embed governance-brain responsibility into Fabric

Planned:

  • normative approval, policy, and governance authority should dock here instead of being hidden as a permanent Fabric responsibility

jhf-tenter​

  • Direction: adjacent shared-runtime
  • Type: runtime-boundary
  • Surface: shared OpenClaw and Fabric substrate only; no direct jhf-warp API callback, no shared broker, no direct write-back path
  • Auth: deployment/runtime boundary only; no direct token contract between jhf-warp and jhf-tenter
  • Stability: planned
  • Versioning: no direct inter-tool API version contract; current coexistence relies on naming isolation, network isolation, and read-first Fabric semantics
  • Owner: jhf-warp-maintainer

Implemented:

  • jhf-warp has no direct API dependency on jhf-tenter
  • current coexistence posture is based on isolated service names, tool-local runtime control, and read-first Fabric metadata consumption

Planned:

  • combined deployment tests should verify restart, order-of-apply, and idempotence on a shared OpenClaw/Fabric base
  • any future direct jhf-tenter integration would need an explicit API and ownership contract instead of implicit shared-runtime behavior
  • shared-runtime coexistence must stay explicit:
  • jhf-tenter may set global agents.defaults.heartbeat
  • jhf-warp therefore pins the Doubtfire control-agent heartbeat posture explicitly instead of relying on inherited defaults
  • when JHF_WARP_DOUBTFIRE_TAKEOVER_HEARTBEATS=true, jhf-warp disables inherited/default and foreign heartbeat blocks so Nikolai Wachter becomes the only heartbeat owner in the shared OpenClaw runtime
  • the current voice contract handoff stays read-model-first:
  • Warp owns AGENT_TOOL_POLICY_CONTRACT, SANDBOX_APPROVAL_POLICY_CONTRACT, VOICE_APPROVAL_POLICY_CONTRACT, VOICE_LIBRARY_GOVERNANCE_CONTRACT, and the voice-enabled agent schema
  • Warp owns the versioned access-model lifecycle vocabulary in docs/ACCESS_MODEL_LIFECYCLE_EVENTS.md
  • Fabric owns the integrated voice binding registry read model
  • tenter consumes those contracts and must not widen them locally
  • current live contract surfaces for Warp-owned voice policy and target truth are:
    • GET /api/v1/voice/policy-profiles
    • GET /api/v1/voice/library-governance
    • GET /api/v1/voice/targets
    • GET /api/v1/voice/targets/default
  • canonical voice-target truth now keeps these routing dimensions explicit and separate:
    • voice_identity_ref
    • voice_runtime_target_ref
    • conversation_agent_ref
  • Voice Identity must not implicitly resolve a runtime or conversation target; consumers must fail closed when target refs are missing or contradictory.
  • Warp consumes the Fabric-owned shared contract families at:
    • GET /api/v1/contracts/matrix
    • GET /api/v1/identity/contracts
    • GET /api/v1/events/access-control/contracts
    • Warp consumes Fabric final voice surfaces at:
      • GET /api/v1/voice/contracts/events
      • GET /api/v1/voice/contracts/binding-registry
      • GET /api/v1/voice/contracts/replay-idempotency
      • GET /api/v1/voice/contracts/time-clock
    • reconcile, revoke, rename, split, merge, and bootstrap transitions must stay explicit and replay-safe; consumers must not widen privilege from duplicate or stale lifecycle events
  • supported operating models are:
    • tenter-only runtime hygiene, when Warp does not install Doubtfire at all
    • Doubtfire-only Warp control-plane with JHF_WARP_DOUBTFIRE_TAKEOVER_HEARTBEATS=true
  • unsupported operating models are:
    • equal heartbeat ownership over the same lane
    • implicit scheduler duplication
    • treating tenter defaults as the policy source for Doubtfire

paperclip​

  • Direction: potential external supervisor / consumer
  • Type: external orchestration boundary
  • Surface: only documented Warp HTTP contracts; no embedded Paperclip runtime inside Warp
  • Auth: same auth and deployment boundary as any other external consumer of Warp
  • Stability: planned
  • Versioning: no direct inter-tool version contract today
  • Owner: jhf-warp-maintainer

Implemented:

  • no direct Paperclip integration exists in Warp today

Planned:

  • if Paperclip is ever used, it may only consume documented Warp surfaces as an external supervisor
  • Paperclip must not redefine Warp runtime truth, Fabric governance truth, or local bundle truth

agency-agents​

  • Direction: incoming content import
  • Type: persona-catalog
  • Surface: vendored markdown under agents/imports/agency-agents/upstream/..., manifest and mapping files, generated agents/profiles/agency-*.md
  • Auth: none at runtime; source is pinned and vendored
  • Stability: partial
  • Versioning: fixed upstream commit plus local manifest checksums
  • Owner: jhf-warp-maintainer

Implemented:

  • Warp consumes agency-agents as pinned persona/workflow source content only
  • imported roles are normalized into a local catalog with explicit provenance
  • current pilot entries are all catalog-only
  • direct upstream OpenClaw installation is not allowed

Planned:

  • later specialist staging may generate Warp-owned overlays and OpenClaw artifacts
  • manager-template activation is explicitly out of scope for V1
  • any re-import with semantic drift must use review-required handling instead of silent overwrite

Synthetic planning bundles​

  • Direction: internal repo-owned planning layer
  • Type: planning-bundle
  • Surface: agents/<department>/<agent-slug>/AGENT.md, PROFILE.json, CV.md, POLICIES.yaml, TOOLS.yaml
  • Policy projection:
    • PROFILE.json -> capability_policy_projection
    • POLICIES.yaml -> capability_policy_projection
  • Auth: none at runtime; repo-local planning artifacts only
  • Stability: partial
  • Versioning: deterministic generation from repo-local synthetic planning profiles
  • Owner: jhf-warp-maintainer

Implemented:

  • Warp materializes deterministic planning bundles for the synthetic permanent manager and specialist profiles
  • bundles remain planning artifacts only and do not auto-activate runtime behavior
  • agency-* imports stay outside this layout because they remain catalog-only
  • doubtfire-control remains on its existing control-agent path as the explicit exception
  • Reed-facing consumers can now read explicit team and approval context from the capability projection instead of inferring grants from role names
  • manifest-v2-oriented consumers can now also read the canonical claim-owner compatibility projection from fabric-manifest.json -> compatibility.manifest_v2_claim_owner_projection

Current Gaps​

  • no remote MCP server endpoint
  • no webhook signature standard
  • no event bus / queue contract
  • no implemented Fabric registration callback
  • no implemented Fabric discovery-specific API beyond the existing read-only surfaces
  • no live multi-tool deployment evidence inside this repository for jhf-pattern + jhf-warp or jhf-tenter + jhf-warp; that remains a downstream jhf-deployment and host-execution responsibility

License​

AGPLv3. See ../LICENSE (LICENSE). Learn more at helpifyr.com.