Every DarDev solution is defined by a single file: solutions/{id}/manifest.json. That manifest is the solution entity—identity, connector graph, content surfaces, pipelines, team access, and switcher visibility—replacing legacy registry.json, tracks.json, overlays, and integrations index files. Ops, the integration bus, and validators all read the same spine; products in Domain C couple only through manifest references, not shared imports.
What the manifest replaces
- registry.json — solution list and switcher metadata
- tracks.json — pipeline actions scattered per track
- ops/integrations/*.json — per-product integration cards
- overlays — duplicate config fragments
- pipelines/index.json — import job registry
One spine reduces drift: when Hesabi adds send.hesabi.tn SMTP identity, engineers edit connectors[] in solutions/hesabi/manifest.json and run ops-validate json-schema validate—not three JSON files that can disagree.
Schema v1 core fields
- version, id, kind (hub|company|product|services|infra), status (active|pending|archived)
- label, accent, tagline — workspace chrome
- visibility.showInSwitcher and requiredRole — gate who sees workspace
- site.url and health — monitoring probes
- github — owner, repo, branch, workflows for CI capabilities
- deploy — target id and runbook doc path
- mail — provider, fromDomain, listSlugs, crmTags summary (authoritative SMTP still in Stalwart/Listmonk)
- connectors[] — typed instances with capabilities
- content[] — news tags, guide ids
- pipelines[] — runsOn, stagingFile, playbook, actions
- operator — hybrid PC pipeline notes
- team — default_role and bindings
- outreach — coldPipeline id, marketingOptInRequired flag
Full spec: docs/architecture/MANIFEST-SCHEMA.md. JSON Schema: packages/contracts/schemas/manifest-v1.schema.json. SOLUTION-OBJECT-MODEL.md explains how connectors, content, pipelines, and team hang off the root entity.
Switcher visibility gate
A solution appears in the Ops switcher only when status is active, showInSwitcher is true, connectors length is greater than zero, and pipelines length is greater than zero. Pending shells—dardevlab, escahire, workspace, dardevcde, dardevops product tile—stay hidden until real connector graph and pipelines land. deployed-realities-explained: we do not show empty workspaces to imply GA.
Connector graph in manifest
connectors[] is the integration surface. Hesabi example: hesabi-crm (crm-twenty with product tags), hesabi-lists (list-listmonk), hesabi-smtp (smtp-stalwart identity send.hesabi.tn), hesabi-dns (dns-ovh zone hesabi.tn), hesabi-repo (github-repo), hesabi-oect (scraper-oect staging path). Each entry lists enabled flag, config object, and capability subset.
20.tn manifest adds scraper-custom for ecoles import and bus-route style connectors for outreach health. DarDev Services emphasizes webhook-inbound routes and services marketing list slugs. Graphs differ; schema is identical.
Pipelines section
pipelines[] declare id, runsOn operator-pc or vps, stagingFile, logFile, playbook markdown path, and optional actions array with script commands. Hesabi includes oect and hesabi-smb pipelines; operator note documents permanent hybrid model.
Bus boot from manifest
Integration bus scans solutions/*/manifest.json at startup and mounts bus.routes[] via handler registry. Manifest-declared routes must be subsets of packages/contracts/bus-route-catalog.json—ops-validate bus-parity enforces this. crm-orchestrates-bus-executes depends on manifests pointing to real handlers for Twenty webhook forwarding and Listmonk sync.
Content surfaces
content[] links news tags to company-news-cms connector, guide ids for in-app docs, roadmaps, landing references. Solution workspace Content tab filters catalog entries—Phase E articles like this one merge from dardev-news/content/drafts through Ops Mail tab.
Validation workflow
- Edit solutions/{id}/manifest.json
- bash scripts/ops/validate/ops-validate.sh json-schema validate
- validate-manifests.mjs and validate-connectors.mjs for cross-refs
- PR CI gate; startup-check.sh warns on local drift
- Deploy Ops and bus; switcher picks up visibility on next load
Migration P1
M8 P1 deliverable: manifest schema plus validator plus migration script; delete legacy registries. Migration maps hesabi.json integration entries into connector instances. Until complete, some panels read legacy files—track in ops/tracker/backlog.json internally; public docs describe target state.
Example: Hesabi manifest slice
Active Hesabi manifest declares kind product, status active, showInSwitcher true after connectors and pipelines validate. site.url points to https://hesabi.tn with health probe interval. github block wires ci-status capability to Dar-Dev-inc/hesabi deploy workflow. outreach block names hesabi-smb coldPipeline and marketingOptInRequired true—manifest documents business rule, Listmonk enforces list membership.
operator.pipelines lists oect and hesabi-smb with note that cold import runs on operator PC. team.default_role operator lets sales run pipeline verify actions; admin required for DNS drift capabilities that call external registrar APIs. This slice shows why one JSON file replaces hesabi overlay plus tracks entry plus integration card.
Example: 20.tn and Services
solutions/20tn/manifest.json registers ecoles-import pipeline with scraper-custom connector, staging path, and playbook link to 20TN-ECOLES-OUTREACH-PLAN. Outreach bus capabilities appear as integration-bus or extended crm connector entries with health and dry-run IDs—manifest points to docs, handlers live on platform bus. DarDev Services manifest emphasizes webhook-inbound routes for site contact and services-outreach sync, list-listmonk for dardev-services-marketing only after opt-in.
Relationship to mail stack
Manifest mail block summarizes fromDomain and listSlugs for Ops display—it does not store SMTP passwords or override Stalwart admin. Authoritative mail config remains Stalwart, Listmonk, Zoho per inside-unified-mailer-stack and ops-orchestrates-never-configures-mail policy.
When onboarding a new solution, copy an active reference manifest (Hesabi or DarDev Services), replace id and connectors, run json-schema validate, and keep status pending until pipelines and health checks pass. connector-capability-runtime-model explains how manifest connectors become UI actions after validation succeeds.
Can a product repo edit manifest directly?
Domain C products reference manifest path in docs; changes land in dardev-platform solutions/{id}/ via PR. Products do not embed Ops code.
What if connectors array is empty?
Solution stays pending; switcher gate fails. Prevents empty shells like legacy M4 stubs.
Where are secrets?
secret_ref on connectors points to VPS env var names. Never plaintext API keys in manifest JSON committed to git.
How does 20.tn differ from Hesabi manifest?
Different connectors and pipelines—ecoles scraper, outreach bus routes, OPT20TN tags—not a different schema.
Which doc is canonical for field definitions?
docs/architecture/MANIFEST-SCHEMA.md plus manifest-v1.schema.json. SOLUTION-OBJECT-MODEL.md for conceptual hierarchy.
