Platform operational contract and OSSA/DUADP supplement¶

Purpose: Section 0 — mandatory behavior for agents (BuildKit-first, no curl-discovery authority, injected auth, CI deploy path). Part III — how OSSA and DUADP relate to golden repos and Cedar.

For “where truth lives” (golden repos, platform-registry.yaml, .agents/ sync, drift rules): read only BLU-GOVERNANCE.md (v1.0). That body is not duplicated here.

Former name: This content lived in PLATFORM-GOVERNANCE.md, which incorrectly bundled the full Master Standard twice. The Master Standard is a single file; this file is the operator supplement.

§0.0 Local orchestration runtime — Gas City (settled 2026-05-06)¶

Gas City (gascityhall/gascity, brew install gascity) is the canonical local multi-agent orchestration runtime for Bluefly.

Role	Component	Does NOT
Runtime/orchestration	Gas City (`gt` CLI, Beads `bd`)	own GitLab, OSSA, ContractPlane, or ContextControl
Personal assistant/client	OpenClaw — Thomas's interactive surface	own orchestration state
Governed agent/persona	Blu — loaded into OpenClaw, routed through Gas City	own session lifecycle
Operator CLI wrapper	`blu-cli` (`blu` command) — wraps Gas City, GitLab, OSSA	reimplement what `gt` provides
Memory authority	ContextControl — summarized durable knowledge	hold raw ledger/session state
Trust/policy	ContractPlane	replaced by Gas City

Key Gas City vocabulary agents must know:

Mayor = primary AI coordinator (gt mayor attach) — Blu fills this role
Polecat = worker agent (Antigravity, Claude Code, Codex)
Rig = per-project container (one per PROJECTS/ repo)
Beads = git-backed work items (analogous to GitLab issues at local level)
Convoy = work batch (maps to an MR group or sprint slice)
Hook = git-worktree persistent agent state (survives restarts)

What blu-cli town commands are: The src/commands/town/ code is a prototype adapter layer — not a replacement for Gas City. Commands like blu gascity status/submit/doctor are the correct wrapper surface. The provisional blu town namespace is retained but documented as adapter-only.

Auth note: Gas City itself does not require 1Password. Only Git/GitLab operations within a Gas City workflow use the approved op run wrappers.

Bluefly Agent Operating Standard¶

Operate in strict enforcement mode. Optimize for correctness, scope control, reduced maintenance, reduced custom code, and shippable outcomes.

0. First Classification Before Any Edit¶

1. Required Behavior¶

Do not assume. Surface ambiguity, missing requirements, contradictions, and tradeoffs before coding.
Minimum viable change. Solve the problem with the smallest correct footprint. No speculative abstractions.
Scope discipline. Touch only the files required for the task.
No unrelated cleanup. Do not rename, move, reformat, delete, or “improve” unrelated code.
No hidden side effects. Do not remove comments, code, configs, or docs outside the task scope.
Define success first. Establish verification criteria before implementation.
Proof before completion. Do not say “done” without evidence.

2. Architecture & Custom Code Reduction¶

Prefer existing systems first. Always prefer Drupal core/contrib, OSSA, DUADP, ContractPlane, Cedar, existing Bluefly repos, and proven open-source tools over new custom code.
Delete/replace before build. For any non-trivial task, check in this order:
Can this be deleted?
Can Drupal core/contrib do this?
Can an existing Bluefly repo/module own this?
Can a proven OSS package do this?
Only then keep or write custom code.
Justify custom code. If custom code remains, state exactly why reuse/replacement is not viable.

3. Ownership & Boundary Enforcement¶

Do not create generic folders, buckets, repos, or “shared” trees when canonical ownership already exists.
Do not move code before classifying responsibility.
Do not mix runtime, governance, infra, product, and docs work in one pass unless explicitly required.
Do not patch contrib directly if a consumer-side override, configuration fix, or upstream-owned fix is more appropriate.
Do not dump declarative specs into runtime repos or runtime code into standards/governance repos.

4. State Discipline¶

Every finding and change must be labeled as one of: - PROVEN - CHANGED_ON_DISK - COMMITTED - BLOCKED Never blur these. Narration is not progress. Edits on disk are not equivalent to committed fixes. A plan is not an implementation.

5. Commit Discipline¶

Commits must be path-scoped, single-purpose, and reviewable.
Do not commit unrelated staged files.
Do not bundle architecture changes, runtime fixes, infra moves, and doc churn into one commit unless inseparable.
Do not leave half-applied fixes behind without labeling them CHANGED_ON_DISK.

6. Documentation Sync Contract¶

These files are for project understanding, not task tracking: - agent.MD - vision.MD - llms.txt - AGENTS.md - CLAUDE.md - ai.json - README.md They must describe: - what the project is - what it owns - what it does not own - dependencies and boundaries - actual model/tool/runtime surfaces - architectural reality after changes After any meaningful code, config, ownership, runtime, or architecture change, explicitly return: - DOC_SYNC_REQUIRED=YES|NO - exact files - exact reason Do not turn understanding docs into to-do lists or action plans.

7. Verification Contract¶

For every meaningful task, define and return: - what was checked - how it was checked - what passed - what is still unverified Preferred verification: - targeted tests - build/lint/typecheck - runtime path verification - diff inspection - config validation - route/API/tool checks - evidence from output/logs If verification is blocked, say exactly what is blocked and why.

8. Blocked Pivot Protocol¶

If blocked by permissions, outages, secrets, ownership ambiguity, or repo state: Do not idle. Pivot immediately to the highest-value adjacent enforcement work: - audit unfinished work - align docs with reality - classify repo drift - identify stale branches/MRs/status docs - identify misplaced files/folders - identify custom code that can be removed or replaced - isolate clean commit boundaries - surface the single highest-ROI next action

9. Explicitly Banned Anti-Patterns¶

Silently choosing formats, protocols, ownership, or architecture without surfacing tradeoffs
Creating new generic structures when a canonical home already exists
Moving code before classification
Conflating layers in one pass
Broad cleanup during a narrow fix
Rewriting adjacent code “because it seemed better”
Claiming success without proof
Leaving docs stale after changing reality
Preserving custom code by default
Stopping at “waiting” when useful audit/cleanup/alignment work remains

10. Business Priority¶

Optimize for: - faster monetization - less manual work - less maintenance burden - less custom code - lower infrastructure/software cost - tighter scope control - reusable components across projects and clients Do not optimize for novelty. Do not build new frameworks when existing systems already fit.

Required Output Contract¶

For every substantial task, the following block MUST be returned: - LAYER: [layer] - OWNER: [exact canonical repo/module/service] - STATUS: [PROVEN | CHANGED_ON_DISK | COMMITTED | BLOCKED] - CUSTOM_CODE_REDUCTION: [YES | NO] - OSS_REPLACEMENT_CANDIDATE: [exact system/module/repo/package | NONE] - VERIFICATION: [exact checks performed] - DOC_SYNC_REQUIRED: [YES | NO] - NEXT_ACTION: [one concrete action]

0. Legacy Workspace Contract Details¶

This section contains specific, detailed platform constraints that support the Operating Standard above.

0.1 What is wrong (never repeat)¶

Live ops against Oracle — No direct ssh / kubectl mutation on Oracle hosts. Oracle SSH is documented as down; approved path is runner-driven operations (e.g. oracle-deploy), not direct host changes.
Discovery-by-curl — Do not treat GitLab API, container registry, or runtime as discovery surfaces to guess topology or images. Topology is declared first, validated in CI, then deployed. Do not infer image names from API results and mutate runtime.
Wrong-repo authority — Do not add registry-map.yaml, Cedar controls, or Lefthook "truth" in agent-docker (or any deploy-only repo) as if that repo owns registry or architecture. agent-docker is build/deploy surface, not the canonical architecture registry.
Speculative image / config edits — Do not rewire copaw or other image references from inference. Without proof through the authority chain, state is UNPROVEN, not "fixed".
Mixed auth models — Forbidden drift between injected auth, local CLI auth, temp env files, and direct token handling. GitLab CLI may document glab auth login and token env overrides; this workspace allows only injected auth for recovery behavior (see 0.5).

0.2 What must align¶

Contract	Rule
BuildKit-first	Use `buildkit` for Git, MR, plans, tunnel, sync—not ad hoc shell loops where tooling is declared.
domains.yaml-first	Runtime topology contract; no manual tunnel edits or ad hoc routing discovery. If `domains.yaml` does not declare it, do not invent it.
CI-only deploy path	Repair = repo change → MR → CI / runner → deploy. No runtime hot-patching as "fix".
Injected auth only	See 0.5.

0.3 Immediate reset (when contract was breached)¶

Stop all live host operations.
Stop all curl-based registry and project discovery loops.
Revert speculative repo changes that invented source-of-truth files or rewired images without proof.
Reclassify every assumption as PROVEN, RUNTIME-OBSERVED, or UNPROVEN. UNPROVEN must not drive a file edit.

0.4 Mandatory preflight (output before any change)¶

For any proposed change, state explicitly:

Canonical owner repo
Canonical source file
Execution path (MR → CI → deploy)
Auth path (op run / BuildKit—never glab auth login)
Evidence tier (PROVEN / RUNTIME-OBSERVED / UNPROVEN)

If any field is missing, stop.

0.5 Authority chain (strict order—no improvisation)¶

domains.yaml — topology and runtime boundaries
ai.json — tooling and flow rules
STATUS.json (plans/__FINAL-PLANS/ where applicable) — current runtime state and blockers
Owning repo + MR — only that repo's files are edited for canonical truth
CI / runner deploy path — oracle-deploy and declared pipelines—not direct prod mutation

Not in this chain: shell output, curl JSON, or "whatever the registry API returned."

0.6 Auth behavior¶

Allowed: op run --account blueflyiollc -- glab api ...; BuildKit GitLab flows where declared.

Forbidden: glab auth login / refresh / logout as recovery; temp token files; echoed token-bearing commands; ad hoc secret handling outside injected runtime.

0.7 Status language¶

Do not say "fixed" unless change is in the canonical repo, MR/CI path is correct, no live env was mutated directly, and post-change proof exists. Otherwise:

Unproven. No canonical fix applied yet. Awaiting declared-state change in the owning repo.

Lifecycle classifier (separate from §0.4 evidence tier)¶

When reporting on a finding or change, mark its lifecycle state from this closed set:

Token	Meaning
`PROVEN`	Verified from code, config, runtime output, or git state. Statement of fact.
`CHANGED_ON_DISK`	Edit made in the working tree, not committed. Reversible.
`COMMITTED`	Change is in a git commit on a feature / fix branch. Not the same as merged or shipped.
`BLOCKED`	Cannot proceed: missing permission, secret, ownership ambiguity, repo state, or external outage.

The §0.4 evidence tier (PROVEN / RUNTIME-OBSERVED / UNPROVEN) describes strength of evidence. The lifecycle classifier above describes where in the change pipeline the work currently sits. Both axes apply; do not conflate them.

0.8 Final instruction¶

Do not derive architecture from shell output. agent-docker = deploy/build only—not registry substitute for domains.yaml or @bluefly/iac.

0.9 Repo task completion (mandatory)¶

Tracked source of truth (Git): blueflyio/gitlab_components — file standards/REPO-TASK-OPERATING-CONTRACT.md (clone path: PROJECTS/gitlab_components/standards/REPO-TASK-OPERATING-CONTRACT.md).

Per platform-registry.yaml, .agents/context/ is not a standalone GitLab product repo (workspace-context / generated-agents-tree use canonical_repo: n/a). Do not treat “edited under $ESTATE_ROOT/.agents” as shipped until the same contract text is merged in gitlab_components on a release/* line (or the hub is wired to a future dedicated meta repo if one is added to the registry).

Rule: Change §0.9 content only via MR to gitlab_components; keep this subsection as a pointer unless the registry gains a dedicated blueflyio meta repo entry.

0.9.1 Documentation sync contract¶

When a change materially shifts project understanding (code, config, ownership, architecture, runtime path, or recommendation), the report must include this block:

DOC_SYNC_REQUIRED:
- agent.MD: YES|NO
- llms.txt: YES|NO
- vision.MD: YES|NO
- AGENTS.md: YES|NO
- CLAUDE.md: YES|NO
- ai.json: YES|NO
- README.md: YES|NO
WHY: <one short reason>

Triggers requiring YES:

agent.MD — repo's ownership boundary, runtime / governance role, upstream / downstream dependency, or canonical relationship changed.
llms.txt — model / provider / runtime usage in the repo changed; AI surfaces added or removed; real-vs-stubbed status flipped.
vision.MD — gap between intended state and actual state changed; custom-code reduction direction shifted; reuse path changed.
AGENTS.md / CLAUDE.md — operator / agent rules changed; new prohibitions or routing.
ai.json — machine-readable contract changed (services, domains, gates, priorities).
README.md — public-facing project description shifted.

These are not todo lists; they are understanding documents. Update them when reality changes; do not back-fill them with task narration.

0.10 Common pitfalls — pointer¶

The full lessons (with incidents, fix recipes, and diagnostic snippets) live in .agents/rules/AGENT-LESSONS-LEARNED.md — that file is the canonical lessons-learned source per the one-topic-one-authority rule. Three load-bearing additions from the 2026-04-26 incident set:

§11 — Path STOP signs. _ON-HOLD/, HOLD-<name>, __DELETE_LATER/, _To-Merge/, .shadowed-modules-backup/, vendor/ in any path = never a target. Canonical Bluefly product sites = PROJECTS/<ProjectName>/.
§12 — Runtime PASS requires logs, not HTTP 200. Mandatory: drush watchdog:show --severity=Error + tail /var/log/nginx/error.log + an authenticated admin-path probe (auth via drush uli --uri=https://<host> over HTTPS for SESS cookie scope).
§13 — Drupal CacheCollector OOM = circular library dependency. Raising memory_limit will not fix it. Find the cycler library with the drush php:eval probe loop in §13.

Read AGENT-LESSONS-LEARNED.md BEFORE mutating composer, services.yml, libraries.yml, or core.extension on any Drupal site.

0.11 Finding output contract (audit / enforcement / review passes)¶

This contract applies to audit, enforcement, gap-analysis, and review passes. Routine implementation tasks continue to use the BLU-GIT.md five-field execution receipt — do not duplicate.

For every finding produced during a qualifying pass, return:

FINDING_ID:
STATUS: PROVEN | CHANGED_ON_DISK | COMMITTED | BLOCKED   # §0.7 lifecycle
OWNER: <repo / module / service>
LAYER: standards | governance | runtime | drupal | infra | product | docs   # see BLU-OWNERSHIP.md Authority Map
RISK: HIGH | MEDIUM | LOW
CUSTOM_CODE_REDUCTION: YES | NO   # see §0.12
OSS_REPLACEMENT_CANDIDATE: <Drupal core/contrib module | OSS package | Bluefly repo | NONE>
EVIDENCE: <file path + symbol or line + exact defect>
IMPACT: <security | governance | runtime | product | maintenance | cost | monetization>
NEXT_ACTION: <one concrete action>
GIT_ACTION: commit | branch | MR | defer | do-not-touch

Do not blur observation and recommendation. Do not return vague summaries without this structure.

0.12 Custom-code reduction matrix¶

Default posture: custom code is debt until proven necessary. Before writing or keeping custom code, walk the decision order in this exact sequence:

Delete. Can this be removed entirely? (Stub, dead scaffolding, duplicate ownership.)
Drupal core / contrib. Entity API, Views, JSON:API, Queue API, Event Dispatcher / subscribers, ECA, Key, Search API, Webform, AI module patterns, contrib MCP / tool integrations.
Existing Bluefly repo. Shared common_npm packages, OSSA manifests, DUADP discovery, ContractPlane evidence / policy gates, Cedar policy packs, compliance-engine PDP, shared MCP infrastructure, runtime repos.
Established OSS package. A stable upstream that fits the boundary, without new compliance or sovereignty risk.
Keep custom. Only if 1–4 do not apply, with a stated reason in the finding.

Verdicts (paired with the §0.11 contract):

KEEP — real, owned, irreplaceable, aligned with platform boundaries.
REPLACE — solved upstream by Drupal / Bluefly platform / OSS, no new governance risk.
REMOVE — stubbed, duplicated, dead, or violates canonical ownership.
DEFER — blocked by secrets / access / rebase / runtime ownership; complete a higher-ROI adjacent step first (see §0.15).

Do not optimize for novelty, speculative abstractions, decorative architecture docs, new generic repos, or extra glue layers when one existing tool / module / repo already fits.

0.13 Fail-closed enforcement (operator / write-time gate)¶

ai.json execution_plane.enforcement_chain is the runtime fail-closed gate (Cedar pre-check, OpenJudge + Cedar post-check, Dragonfly verification, audit commit). This subsection is the write-time complement: before merging or shipping a change to a state-changing path, verify in the file that the path is governed.

State-changing paths (always treat as governed unless proven otherwise):

Tool plugins; REST resources; JSON:API write paths; queue workers that mutate state.
Service methods that save entities; controllers / forms that submit; CLI commands that write.
AI / agent dispatchers; MCP write / invoke handlers; memory write / read services.
Approval / policy / lease code paths.

For each, the file under review must answer YES to all of:

Cedar / ContractPlane evaluation present — the path is gated by, or proxies through, a governance evaluator. Direct entity writes when a guarded service exists are an enforcement defect.
Tenant isolation respected — no cross-tenant leakage; tenant_id flows from request to storage.
Idempotency present — repeated invocations with the same intent do not double-write.
Deduplication present — at-least-once delivery does not produce duplicate state.
No split-brain path — there is no parallel ungoverned API doing the same write.

Flag any fail-closed config defaulting to permissive (fail_closed: false, optional policy evaluation with silent pass-through, missing auth on a service endpoint, default-allow on network or service failure, permissive trust-tier fallback) as an enforcement defect, not a config preference.

0.14 Required audit passes¶

For any audit / enforcement / review pass, run all five and report findings under §0.11:

Enforcement pass. Grep for direct entity.create / entity.save / storage writes; REST write handlers; tool / plugin execute paths; MCP write / invoke handlers; bypasses around policy / guard services.
Stub pass. Grep for mock, stub, fixture, placeholder, fake, temporary, for now, TODO, FIXME, uniqid() in action paths, hardcoded metrics, controllers returning static payloads, SSE streams serving fixture events, context scopes returning unresolved token strings. Classify each as: demo-only-acceptable, must-be-wired, should-be-deleted, should-move-to-tests.
Replacement pass. For each custom controller / service / plugin, walk the §0.12 matrix.
Git-state pass. Classify the repo into one of: SAFE_TO_COMMIT_NOW / REVIEW_BEFORE_COMMIT / BLOCKED_BY_REBASE_OR_CONFLICT / DO_NOT_TOUCH / POINTER_ONLY / SUBMODULE_ONLY. Never lump multiple repos into one command blob.
Doc-drift pass. For every changed area, ask: does agent.MD / llms.txt / vision.MD / repo README.md / AGENTS.md / CLAUDE.md / ai.json still match reality? Use the §0.9.1 DOC_SYNC_REQUIRED block.

The runner playbook (mechanical patterns, exact greps, path lists) lives in .agents/workflows/antigravity-audit.md — cross-reference, do not duplicate.

0.15 Blocked-work posture¶

When the primary action cannot proceed (missing credential, external outage, missing permission, ownership ambiguity, repo mid-rebase), do not idle. Switch immediately to the highest-value adjacent work from this set:

audit unfinished work in the same repo or area
classify drift (what is changed-on-disk, what is committed, what is stale)
align understanding docs with reality (§0.9.1)
identify stale branches / MRs / status files
identify custom-code replacement candidates (§0.12)
verify ownership boundaries against BLU-OWNERSHIP.md
tighten commit scopes
surface the single highest-ROI next concrete action

"Stop with waiting" is out-of-contract. If you cannot proceed and no adjacent work applies, report:

exact file or path not writable / not accessible
exact command attempted
exact next command the operator must run

Then stop. Reporting blockers without those three exact fields is also out-of-contract.

0.16 Deployment authority: DUADP vs local developer surfaces¶

The deployed runtime authority for agents, skills, tools, runtimes, and capabilities is DUADP — not workspace filesystem state, not symlinks, not local registry files. Local .agents/ and .agents-workspace/ trees are developer / cache / projection surfaces only.

Roles:

PROJECTS/agents is the authoring / source repo for platform agent manifests.
openstandardagents validates and exports OSSA manifests.
DUADP publishes and discovers deployed agents, skills, tools, runtimes, and capabilities (https://discover.duadp.org, GET /.well-known/duadp.json, GET /api/v1/agents | /skills | /tools).
.agents/ and .agents-workspace/ are local developer / cache / projection surfaces only — authoring ergonomics, offline cache, validation input, projection staging.
PROJECT/.agents/ is a project-local contract that references DUADP IDs, not workspace filesystem paths.

Forbidden:

Do not propose symlinks as deployed authority.
Do not make <operator-workspace>/.agents a production dependency.
Do not make PROJECT/.agents reference workspace filesystem paths for runtime execution.

Hard rules:

If deleting .agents-workspace or breaking the .agents symlink affects production, the architecture is wrong.
If production cannot resolve agents from DUADP alone, the architecture is wrong.

Reference shapes (use in any new agent / skill / tool reference):

# Deployable / runtime mode (default for any consumer that runs in production)
resolution_mode: duadp
duadp_uri: duadp://bluefly/agents/<agent-id>
version: <semver constraint>
checksum: <sha256 if pinned>

# Local / developer mode (allowed only for authoring, validation, or offline work)
resolution_mode: local
source_path: Applications/agents/.agents/...

Final sentence (canonical):

Agents are authored in Git, validated/exported by openstandardagents, published/discovered through DUADP, governed by Cedar/ContractPlane, executed by Blu/OpenClaw, tested by Dragonfly, and cached locally only for developer convenience.

Bridge: Section 0 vs Master Standard¶

Section 0 constrains how agents act (no curl discovery, no wrong-repo files, injected auth, CI path).
Master Standard defines where truth lives (golden repos, registry file, sync model). See BLU-GOVERNANCE.md.

platform-registry.yaml (Master Standard §6) vs domains.yaml (Section 0):

domains.yaml — authoritative for runtime topology, service URLs, deployment boundaries.
platform-registry.yaml — authoritative for repo roles, GitLab paths, local clone paths, consumers, release mechanisms—the structural map agents read before editing.

If registry and filesystem disagree on clone path, update registry + align filesystem via MR (Master Standard §6). If domains.yaml and registry disagree on URLs or service names, domains.yaml wins for runtime; fix registry or domains in the owning repo—do not invent routes.

Part II (Master Standard v1.0) — single source¶

The full Platform Governance Master Standard (sections 1–17: canonical homes, golden repos, registry, sync, drift, documentation contract) is maintained in one file only:

BLU-GOVERNANCE.md

Do not paste or fork that body into other files.

Part III — OSSA (agent contract) and DUADP (discovery protocol)¶

Research basis: duadp.org and openstandardagents.org (public protocol and spec pages; cite current version in docs when executing).

III.1 Protocol stack (how pieces relate)¶

Layer	Role	Answers
MCP	Tools and context	What tools/data can the model use?
A2A	Agent-to-agent comms	How do agents talk to each other?
OSSA	Open Standard for Agents — portable agent manifest contract (spec)	What is this agent (identity, capabilities, governance, skills refs), validated manifest, exports to many targets
DUADP	Decentralized Universal AI Discovery Protocol — federated discovery	How agents, skills, and tools are found and published across a mesh (GAID/DID, WebFinger, federation, REST + MCP tools)

OSSA does not replace MCP or A2A: it is the contract artifact (YAML manifests, validation, export). DUADP provides DNS-like discovery for that ecosystem: publish once, discover across nodes—aligned with OSSA manifests and validation.

Cedar (platform policy bodies) remains in cedar-policies (Master Standard). OSSA manifests may reference or embed policy intent for runtimes; authoritative .cedar source and policy packs still flow from cedar-policies and compliance/evaluation paths—not from ad hoc copies in consumer repos.

III.2 OSSA — `openstandardagents.org`¶

Spec / CLI: @bluefly/openstandardagents — ossa init, ossa validate, ossa export to many deployment targets (Docker, K8s, GitLab, Cursor, Drupal, MCP, etc.).
Contract: Schema-validated manifests; GAID (DID-oriented global agent id) for identity; trust tiers; compliance metadata; skills pipeline in spec (skills are packaged and exported—not authored only inside .agents/).
MCP: OSSA ships MCP tools (ossa_validate, ossa_publish, ossa_list, workspace helpers) so IDEs validate and publish without hand-rolling HTTP.
Drupal: Manifests import via ai_agents_ossa / Drush—consumer path, not a second authoring truth (Master Standard §11).
Bluefly mapping: PROJECTS/platform-agents and PROJECTS/agentic-marketplace are where source is authored and reviewed; ossa packages and exports; .agents/ remains a generated projection after upstream merge/release (Master Standard §8).

III.3 DUADP — `duadp.org`¶

Purpose: Federated discovery for agents (and skills/tools listings)—no single silo; nodes expose /.well-known/duadp, WebFinger, optional gossip federation.
Identity: GAID as stable handle (e.g. agent://discover.duadp.org/agents/...); DID (did:web, etc.) for cryptographic identity; signatures and provenance; trust tier feeds Cedar-style policy inputs for discovery/publish/federation gates.
API surface: Browse/search agents, skills, tools; publish; validate OSSA manifests; federation list/register/gossip; governance/NIST-aligned evaluation hooks (per public docs).
MCP: Reference node exposes MCP tools (duadp_list_agents, duadp_list_skills, duadp_list_tools, duadp_search, duadp_publish_agent, duadp_validate_manifest, federation and governance tools) so assistants discover and register through the protocol, not ad hoc scripts.
Package: @bluefly/duadp (npm); self-hosted nodes supported.

III.4 How we manage agents, skills, tools, and policies (end-to-end)¶

Author agents in platform-agents, skills in agentic-marketplace, Cedar sources in cedar-policies (Master Standard).
Validate / package with OSSA (ossa validate, exports) and repo CI.
Publish / register to DUADP (and internal marketplace surfaces) using declared pipelines—not manual curl loops as architecture authority (Section 0).
Discover for operators and IDEs via DUADP MCP tools or documented REST, against released identities; parity checks ensure DUADP matches golden-repo releases (Master Standard §9.2).
Enforce runtime policy via Cedar from released packs + execution/compliance paths; trust tier from DUADP/OSSA identity chain is an input to policy, not a substitute for cedar-policies bodies.

III.5 Alignment with Section 0 (non-negotiable)¶

DUADP and OSSA docs are not replacements for domains.yaml. Service URLs, tunnels, and deployment topology come from declared workspace files and owning repos—not from improvising based on discovery API output.
No "discovery-by-curl" as source of truth: Using DUADP/GitLab APIs to audit parity or list published resources in CI is allowed when scripted as BuildKit/CI checks against known golden-repo tags. Using live API results to guess image names, routes, or registry layout without the authority chain (Section 0.5) is forbidden.
Publish path: Still MR → CI → release → register; DUADP publish happens after canonical repo truth is merged, not instead of it.

III.6 Documentation actions (on execute)¶

Keep stable links to duadp.org/docs and openstandardagents.org specification/getting-started.
platform-registry.yaml entries for platform-agents / agentic-marketplace should include release_mechanism and duadp_surface (or equivalent) where applicable so agents know OSSA export and DUADP registration steps.

Appendix — Layer diagram (reference)¶

flowchart TB
  subgraph declared [Declared runtime]
    DY[domains.yaml]
    AJ[ai.json]
    ST[STATUS.json]
  end
  subgraph sources [Golden repos]
    PA[platform-agents]
    AM[agentic-marketplace]
    CP[cedar-policies]
  end
  subgraph packaging [Packaging]
    OSSA[ossa CLI]
    DUADP[DUADP registry]
    CedarRel[Cedar releases]
  end
  subgraph runtime [Runtime via CI runner]
    Drupal[Drupal etc]
    Exec[execution plane]
    Compliance[compliance PDP]
  end
  subgraph local [IDE]
    Ctx[.agents/context]
    Gen[.agents generated]
  end
  DY --> Exec
  PA --> OSSA
  AM --> OSSA
  CP --> CedarRel
  OSSA --> Gen
  OSSA --> DUADP
  CedarRel --> Compliance
  CedarRel --> Exec
  PA --> DUADP
  AM --> DUADP
  Gen --> Drupal
  Ctx --> Gen

Re-upload any authority docs not in session before tightening CI or registry fields.

Appendix A — Consolidated operator rules (merged)¶

This file is intentionally the single operator/agent behavioral contract surface for the workspace. Any prior split between “contract”, “governance”, and “operator rules” is merged here to avoid sprawl.

A.1 GitLab / MR / release targeting (summary)¶

Work on feature branches; deliver via MR.
Target the release train (release/*, e.g. release/v0.1.x) unless a repo explicitly documents otherwise.
Never force-push. Prefer merge pulls over rebases on shared branches.
MR URL discipline: never paste an MR link unless verified via GitLab API in the same turn (MR exists, branches match, and head pipeline not failed/canceled).

A.2 SSH + secret handling (summary)¶

Bluefly Git remotes must use git@gitlab-bluefly: (SSH config alias).
Workstation secrets are injection-only via op run / op inject (see BLU-AUTHENTICATION.md).

A.3 Governance / “where truth lives” (summary)¶

Golden repos own authored truth; .agents/ and .agents-workspace/ are generated projections.
Workspace control-plane context stays small (see .agents/context/README.md).

HARD ENFORCEMENT — anti-sprawl rules (non-negotiable)¶

These rules exist to stop agents from creating stale content you have to maintain.

Rule 1 — No new doc in `.agents/context/`¶

No new document is allowed in .agents/context/ unless an existing canonical file cannot absorb the change.

Rule 2 — If a new doc is created anywhere under `.agents/`, justify it first¶

Before creating a new file under .agents/, the agent must state:

why existing docs are insufficient
why this is not config
why this is not a rule
why this is not workflow metadata

Rule 3 — No date-prefixed files in canonical context¶

No date-prefixed files in .agents/context/.

Rule 4 — One topic, one authority file¶

No topic gets more than one authority file. Examples:

domains/topology → domains.yaml
secrets/auth → BLU-AUTHENTICATION.md
git/branching/MRs/release targeting → BLU-GIT.md
operator conduct/escalation → BLU-OPERATOR-CONTRACT.md
workspace layout → BLU-WORKSPACE.md
ownership/authority boundaries → BLU-OWNERSHIP.md

Rule 5 — Narrative plans do not belong in `.agents/context/`¶

Plans are not canonical context. Keep them out of .agents/context/.

Rule 6 — Tool config JSON never belongs in `.agents/context/`¶

Machine/tool config belongs in .agents/config/. Testing config belongs in .agents/testing/.

Appendix B — Emergency Business Impact Window (pointer)¶

The current operating window's monetization / time / maintenance / scope priorities live in .agents/config/ai.json under portfolio_model.emergency_business_impact_window. The JSON is canonical (machine consumers read it directly); this appendix is a pointer so prose readers know where to look.

When the window is active: true, lean into the listed priorities and away from the listed anti_priorities for any judgment call between alternatives. The sunset_review_date is the trigger to re-evaluate; do not silently entrench the window past that date.

The machine-readable mirror of the §0 enforcement spine (status classifier, finding contract path, custom-code reduction path, fail-closed checks path, audit passes path, blocked-work posture path, doc-sync contract path) lives at the top level of the same file under claude_code_operating_mode.