Publishing to the marketplace

This page specifies a proposed publishing workflow for connector and operator listings. The public command, automated submission path, and third-party marketplace program are not available today. Managed proposals may be reviewed individually with the Fibric team; only five listings are evidenced on the live BearScope path.

#Listing metadata requirements

A listing has two layers: the card shown in the marketplace grid, and the detail page behind it. Every field below is real; these are the fields the live catalog is built from, and review checks each one.

#Card fields

#Detail page fields

#A complete listing.json

The listing travels with the project as listing.json. This example is complete: every required card and detail field, in the register the marketplace expects.

{
  "id": "cn-brightdesk",
  "name": "Brightdesk",
  "category": "comms",
  "type": "connector",
  "caps": "reads conversations and SLA state · writes notes back idempotently",
  "blurb": "Reads Brightdesk conversations as governed events and writes notes back under idempotency, so a retried write is a safe no-op.",
  "tags": ["support", "cx", "conversations", "helpdesk"],

  "tagline": "Brightdesk conversations in, notes back — idempotently.",
  "about": [
    "The Brightdesk connector reads conversations, messages, and SLA state as governed events: every thread stamped with its tenant, its source, and the moment it changed, so an operator sees the conversation the way an agent would.",
    "Writes go the other way under the same discipline: notes are idempotent, so a retried write collapses into the original rather than duplicating. Side effects run only through the deterministic executor, behind the tenant's trust policy."
  ],
  "senses": [
    "Conversations and messages as they arrive and change",
    "SLA state and breach events per conversation",
    "Customer records with contact history"
  ],
  "acts": [
    "Writes notes to a conversation, idempotently",
    "Updates conversation status and assignment"
  ],
  "auth": "A Brightdesk API key with the scopes you grant, stored in your tenant's secret store.",
  "requires": [
    "A Brightdesk instance and an API key with conversation read and note write scopes"
  ],
  "worksWith": ["op-order-sentinel", "op-radar-analyst"]
}

#Submitting

fibric publish validates the def and the listing together, then submits the proposal for review. Nothing becomes visible to other tenants at this point.

$ fibric publish ./connectors/brightdesk
  validating def          cn-brightdesk@1.0.0  ok
  validating listing      listing.json          ok
    card: id, name, category, type, caps, blurb, tags        ok
    detail: tagline, about[2], senses[3], acts, auth,
            requires, worksWith                              ok
    worksWith references resolve: op-order-sentinel, cn-magento  ok
  running contract tests  4 tools, 3 events     ok

  submitted proposal pub_01j9x2 for review.
  status: proposed. the Fibric team will follow up on this proposal;
  track it with: fibric publish --status pub_01j9x2

#The review process

Publishing is a managed early-access design, not a public program. Any proposal is reviewed individually with a person on the other end; there is no automated approval path. A managed review would cover four things, in order:

1. Contract. The def satisfies the SDK contract: every tool validates its input, every side-effecting tool is flagged sideEffecting, the declared auth kind matches how the connector actually authenticates, and the probe answers.
2. Secrets. No credential material in code, config, or logs, per the secret handling rules. This is the most common reason a proposal goes back.
3. Listing accuracy. Every claim in about, senses, and acts is checked against the tool and event surface. Production-use claims require a running deployment the team can verify.
4. Behavior. The team runs your fixture corpus through the harness and exercises the tools against a sandbox connection you provide. For operator packs, the prompt contract and guardrail defaults get a dedicated read.

Expect dialogue rather than an automated verdict. The five live listings establish the current BearScope proof set; no general review-turnaround SLA is published.

#Pricing your listing

Pricing is part of the proposal and shows on the detail page. The platform's standing terms frame what you choose:

Any commercial structure is negotiated during managed review and becomes binding only in a written quote or agreement. There is no public publisher registration, checkout, payout cadence, or marketplace fee schedule today.

#Status lifecycle

Every listing moves through three states, and only review moves it forward:

Status attaches to the public catalog record in this target model. Version review, deprecation, retention, and support windows are managed and contractual; this reference does not promise perpetual installability or a public upgrade service.

#Updating a live listing

Publishing a new version of an existing listing is the same command against the same id with a bumped version. What review looks at depends on what changed:

• Listing-only changes (a sharper tagline, an added worksWith reference) are reviewed for accuracy only and typically turn around fastest.
• Patch and minor artifact versions get a contract re-check and a fixture replay. The listing keeps its status.
• Major versions, anything that adds a required capability, changes the auth kind, or (for packs) alters guardrail defaults, get a fresh behavioral review before the version is offered to installers.

Existing installs are never force-upgraded. A tenant running cn-brightdesk@1.0.0 keeps running it after 1.1.0 ships; the upgrade is their decision, made against the diff the marketplace shows them.

#Keep going

• Testing connectors: the fixture corpus and CI gates review expects you to arrive with.
• defineConnector(): the def the listing must accurately describe.
• Operator packs: the extra review surface packs carry, prompt contract and guardrails.
• CLI reference: fibric publish flags and output in full.