Skip to content

ADR-0017 — Repository Capability Convergence Audit

  • Status: Proposed
  • Date: 2026-07-27
  • Related: ADR-0023 (repository-authority-model), ADR-0010 (repos-governance-authority), ADR-0011 (oracle-upstream-convergence)

Context

The Bluefly platform accumulates repositories and custom Drupal modules over time. Per the Upstream Capability Discovery doctrine (native → config → plugin/extension → official SDK/API → maintained package → smallest Bluefly adapter last), every piece of custom code must justify why a higher-priority owner cannot absorb it. This audit answers, per repository/module: "Does Bluefly own this because it must, or because it historically accumulated it?"

Before deprecating any repository or module, capability preservation requires answering: 1. What capability disappears? 2. Who owns it afterward? 3. Is that ownership upstream? 4. Is migration proven?

This content was previously drafted at Archives/repository-convergence-audit.md on a NAS-mounted working copy. Archives/ is git-ignored (.gitignore, grouped under "Gas City runtime state — never commit"), so that copy was never version-controlled. Per rules/documentation-production-rule.md Ownership Decision Tree step 6 ("Neither Layer 1 nor Layer 2? → Create a task or ADR proposing the correct owner"), this content is promoted here as the tracked, canonical copy. The Archives/ copy is now a superseded duplicate.

Decision

Platform repository audit matrix

Repository Upstream Overlap Unique Capability Candidate Owner Evidence Confidence Decision
agent-docker High Deployment conventions iac / Upstream High Candidate for convergence
workflow-engine High Unknown TBD Medium Needs capability audit
agent-router High (Routing) / Low (ContractPlane) Contract negotiation, routing policy Split (LiteLLM + ContractPlane) High Split and evaluate
agent-brain Medium Reasoning, context assembly TBD Low Needs capability audit
compliance-engine Cedar policy language/evaluator; AuthZEN for optional standard API Compliance decision service consuming canonical cedar-policies compliance-engine High Preserve as Compliance-as-a-Service API
iac Low Deployment, provisioning iac Proven Elevate as authority

Detailed repository evidence

  1. agent-docker — Provides Docker Compose definitions, scripts, and runtime wiring for the entire platform. Overlaps with declarative responsibilities already owned by standard IaC (Terraform) or upstream schedulers. Candidate owner: iac (Terraform/Cloud-init) and upstream deploy manifests.
  2. workflow-engine — Custom orchestration for LLM workflows, DAGs, integrations. High overlap with DAG orchestration/retries/state. Candidate owner TBD — evaluate Temporal, n8n, Langflow, Gas City against required capabilities; smallest owner wins.
  3. agent-router — AI gateway: routing, failovers, cost budgets, discovery. Splits into a commodity layer (model providers, retries, budgets — owned by LiteLLM) and a Bluefly layer (capability routing, contract negotiation, topology, governance — retained as ContractPlane).
  4. agent-brain — Vector search, knowledge graph resolution, agent context memory. Retrieval infrastructure is not equivalent to reasoning: databases/vector indexes are upstream; semantic compression, provenance, context assembly, ranking, domain reasoning may remain legitimate Bluefly capabilities if they provide differentiated business value. Needs audit.
  5. compliance-engine — Bluefly Compliance-as-a-Service API consuming the canonical Cedar policy library at /Volumes/AgentPlatform/Applications/cedar-policies. Preserve as-is; evaluate AuthZEN only as an optional external interoperability interface, not a redefinition.
  6. iac — Terraform, tunnels, core foundation definitions. Low upstream overlap, correctly uses upstream tools. Elevate as primary authority.

Drupal module ownership convergence matrix

Phase 1 deliverable — forces every custom Drupal module through the ownership funnel. Each line of custom PHP must answer: "Why can't a higher-priority owner own this?"

Ownership funnel (priority order):

Priority Owner Rule
1 Drupal Core If core provides it, delete yours
2 Contrib Module If a maintained contrib does it, use that
3 Recipe If config-only, make it a recipe
4 ECA If event→condition→action, use ECA
5 AI Module (contrib) If AI abstraction exists in drupal/ai, use it
6 MCP Tools If tool-callable, expose via MCP
7 OSSA Agent If agent-scoped, define in OSSA manifest
8 Bluefly Custom Only if no higher owner can absorb it

Summary:

Action Count Modules
RETIRE 2 ai_provider_apple, charts_ai_analytics
CONTRIBUTE 11 ai_agents_ossa, ai_agents_client, layout_system_converter, ai_agents_communication, ai_agents_marketplace, ai_agents_agui, ai_agents_kagent, ai_agents_orchestra, code_executor, blockchain_manager, ai_agents_tunnel
EVALUATE 3 mcp_gateway, alternative_services, playbook_engine
RETAIN 13 contractplane_client, kb_cache, cedar_policy, duadp_client, blu_fleet, openclaw, copaw_bridge, dragonfly_client, dita_ccms, simple_age_gate, agentic_canvas_blocks, source_connect, skills_browser
NOT EVALUATED 4 agent_api, agentdash_platform, api_normalization, recipe_onboarding
TOTAL 33

RETIRE (2 modules): - ai_provider_apple — custom plugin duplicates contrib; upstream drupal/ai added Apple provider support. - charts_ai_analytics — charts module + AI module automators cover this.

CONTRIBUTE (11 modules) — to be extracted and submitted to drupal.org contrib or Packagist: ai_agents_ossa, ai_agents_client, layout_system_converter, ai_agents_communication, ai_agents_marketplace, ai_agents_agui, ai_agents_kagent, ai_agents_orchestra, code_executor, blockchain_manager, ai_agents_tunnel.

EVALUATE (3 modules) — pending code review against existing upstream solutions: mcp_gateway, alternative_services, playbook_engine.

RETAIN (13 modules) — encode Bluefly-specific governance, identity, or platform integration logic: contractplane_client, kb_cache, cedar_policy, duadp_client, blu_fleet, openclaw, copaw_bridge, dragonfly_client, dita_ccms, simple_age_gate, agentic_canvas_blocks, source_connect.

  • skills_browser — current-state implementation of record, not a candidate for retirement. Originally listed as RETIRE ("superseded by OSSA agent capability model + MCP tool surface"); that claim was never checked against what OSSA/DUADP actually ship. Per-capability disposition (audited 2026-07-27):
  • Drupal admin browsing UI: Consumes Drupal's project_browser contrib module.
  • .well-known/drupal-agent-skills runtime discovery endpoint: current Bluefly implementation of record within the surveyed ecosystem. No equivalent implementation was identified during this survey.
  • Skill Repository / Skill Definition entities: same status — current implementation of record; no equivalent identified during this survey.
  • SkillsShClient: Consumes skills.sh (confirmed pure discovery/leaderboard site, GitHub-repo distribution, no API or well-known endpoint of its own).
  • Relationship to OSSA: Complements — OSSA's agent-package model (manifest.ossa.yaml, skills/, exports/) is a different object than a Drupal skill registry.
  • Relationship to DUADP: Prospective delegation target, not current — duadp.org is an empty placeholder repo; its own roadmap lists federation protocol authoring as a future P1 sprint item, not shipped work.
  • Replacement status: Not established. Revisit only when DUADP ships a working federation protocol/runtime.
  • Re-evaluation trigger — reopen this disposition when any of the following occurs:
    • DUADP publishes a functioning federation/runtime implementation.
    • OSSA introduces an equivalent Drupal skill-registry capability.
    • skills.sh exposes a machine-consumable discovery protocol (not just its current human-browsable catalog).
  • Assessed against: DUADP and OSSA at BluCity-Docs commit 6f27427e (2026-07-24, products/DUADP/duadp.org/README.md and products/OSSA/OpenStandardAgents.org/Agent-Skills-Implementation-Plan.md); skills.sh and grasmash/drupal-claude-skills — live sources, checked 2026-07-27.

NOT EVALUATED (4 modules): agent_api, agentdash_platform, api_normalization, recipe_onboarding.

Rule

Do not retire working software because another project has a design document or roadmap entry. Classify capability relationships precisely — Consumes / Complements / Prospective delegation target / Current implementation of record / Not established — rather than collapsing to a binary retire-or-keep. Retirement requires a proven, shipped replacement per the Ownership Funnel above, not an aspirational one.

Consequences

  • RETIRE count is 2 (was 3); RETAIN count is 13 (was 12) pending this ADR's acceptance.
  • EVALUATE and NOT EVALUATED items remain open — this ADR does not close the full audit.
  • Archives/repository-convergence-audit.md is superseded by this document and should not be further edited as if it were canonical.