Contract: plugin.toml

Status: Accepted

The interface between lemonfiber and a plugin. Everything lemonfiber will do on a plugin’s behalf comes from this file; it knows nothing about a plugin that is not declared here.

Satisfies: F3-R1, F3-R2, F3-R8, F3-R10, F3-R14, F3-R23, F3-R24, F3-R21, F3-R22, F4-R1, F4-R4, F4-R14, F3-R17, F3-R18, F3-R31, F3-R33, F3-R34, F3-R35, F1-R9, F10-R12

---

Why this file exists

ADR-0021 decided that a plugin is declarative data and that lemonfiber writes its Compose entry rather than accepting one. This says what that data is. ADR-0043 made that data the one model every Compose entry is written from, the stack’s own services included.

It is a second manifest rather than a use of the first because the two describe different things. stack.toml describes a whole stack — its profiles, its forms, and the complete set of services that constitute it. A plugin describes one addition to a stack that already exists, and the difference is not cosmetic: a fork replaces the stack and is the operator’s own work, unattributed and unjournalled (F1-R3); a plugin is a stranger’s work added to a running system, and every one of its changes has to be attributable and reversible (F7-R1). Overloading one file with both verbs would mean a document whose meaning depends on how it arrived.

What this version covers

This describes the additive plugin: one that adds a service to a stack. That is the whole of what a plugin is in the version that introduces the format, and it is deliberately the smallest thing that is genuinely useful — a service that runs, is health-gated, appears in status, is journalled and can be removed.

Recipes, the hosts they reach, the values they capture and the bundled settings they override each add a block to this file in the version that introduces them. Every one of those additions is additive: a manifest written against this version stays valid, which is the property that lets the format get real use before 1.0.0 freezes it.

File location

plugin.toml, at the root of a plugin’s source — a git repository or a directory. One plugin per source; a source declaring two is refused rather than resolved, because “which one did I install” has no good answer.

Top-level structure

schema_version = 1

[plugin]          # identity and provenance
[[service]]       # what runs — one or more
[[claim]]         # a core capability, and the probes that demonstrate it
[[ask]]           # a core capability one of its services asks for
[[wiring]]        # how the stack's own proxy and dashboard reach one service
[[proof]]         # what must hold before it is installed
[[contribution]]  # a row at a published extension point
[[recipe]]        # the ordered calls that configure what it installed (F8)
[[secret]]        # every value it will hold (F3-R17)
[[override]]      # every bundled thing it will change (F3-R18)
[requires]        # what the plugin needs of lemonfiber

[[secret]] and [[override]] are filled in by a manifest whose recipes capture or change anything (F8), and are absent otherwise. F3-R17 and F3-R18 fail validation on an undeclared secret or override, and a format with no place to declare one cannot enforce that.

[plugin] — identity and provenance

[plugin]
id          = "plex"
name        = "Plex Media Server"
version     = "1.2.0"
description = "Plays your library on TVs, phones and browsers"
without_it  = "Files on disk, no way to watch them"
upstream    = "https://github.com/plexinc/pms-docker"
license     = "Plex-EULA"
forms       = ["library", "full"]

description and without_it are required of a plugin for the same reason they are required of a bundled service: the catalogue exists to convert an inventory into a judgement about severity, and a plugin that appears in lemonfiber ps without them puts a name in front of an operator and nothing else.

The licence is declared but not constrained. Every bundled service is OSI-licensed, bar the images lemonfiber builds from its own code, which carry lemonfiber’s own licence, and F2-R5 fails validation on anything else, because the bundled set is a curated list this project stands behind. A plugin is not: the operator chose it. Refusing to install proprietary software on somebody’s own machine would be F1’s objection exactly — the tool standing between an operator and their stack. So the licence is recorded and shown, including on the lemonfiber plugins read (F7-R5), and the operator decides. A plugin whose licence is absent is refused; one whose licence is merely not open is installed and said so.

There is deliberately no min_lemonfiber_version. stack.toml has one, and a plugin has none on purpose: F3-R21 requires an unmet requirement to be refused by naming the capability rather than a version. See [requires].

[[service]] — what runs

Each service a plugin runs is declared in the one service model every Compose entry is written from, in the fields stack.toml declares its own services in: the image by digest, ports, mounts, environment, who it runs as, shapes and what it provides. The whole of [[service]] is on its own page.

What lemonfiber writes

A plugin’s service gets its own profile, named for the plugin, which is added to the closure of each form the plugin declared (ARCH-R96). Its own profile rather than an existing one, because a profile is the unit that starts and stops together, and a stranger’s service joining tv would mean lemonfiber up tv could no longer be described without naming what is installed.

The core writes that profile as plugin-<id> and adds it to no form’s closure: an install starts it alone, a removal takes it down alone, and lemonfiber up <form> names only the profiles the stack’s own forms declare. 0.18.0 locks ARCH-R96.

A first-party plugin’s services sit in the profile the bundle assigns it instead, assembled or installed, so a part keeps the profile it has as a stack service and lemonfiber up tv starts the parts it always started (ARCH-R96). The manifest names no profile either way: a substitute and the part it stands in for are declared in the same vocabulary, and only the bundle places a part.

From the declarations of every service, the stack’s and every plugin’s, lemonfiber generates one Compose project (ARCH-R224). Nothing in it is read from a file somebody wrote: there is no fragment, no shared template and no overlay. For the Plex declaration above, the entry is:

plex:
  image: docker.io/plexinc/pms-docker@sha256:4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945
  profiles: [plugin-plex]
  restart: unless-stopped
  environment:
    TZ: ${TZ}
    PLEX_CLAIM: ""
  ports: ["${LAN_BIND}:32400:32400"]
  volumes:
    - ${DATA_ROOT}:/data
    - ./config/plex:/config
    - ./config/plex/transcode:/transcode
  security_opt: ["no-new-privileges:true"]
  cap_drop: [ALL]
  cap_add: [CHOWN, DAC_OVERRIDE, FOWNER, SETGID, SETUID, KILL]
  devices: ["/dev/dri:/dev/dri"]
  group_add: ["${RENDER_GID}"]
  pids_limit: 1024

Every line comes from one place:

The only substitutions an entry carries are the variables lemonfiber writes itself: the interface a tier renders, the data root, the operator’s uid and gid, the time zone and the render group. Everything a manifest supplied is written as a literal.

That is the whole of it. There is no field in plugin.toml that adds a line outside that table, which is what makes “what can this service reach” answerable from the format rather than from the instance; only the operator’s own overlay changes it, and it is shown as unvetted wherever it does. A service that is native-mode on the host (host_managed) gets no entry.

The project is lemonfiber’s output, not a file to edit: a service changes by changing its manifest. An edit made to the generated project is a locally modified materialised file, detected by content and never overwritten without a diff and confirmation (F1-R4).

The operator’s overlay

An operator whose service needs something the model cannot say writes it in an overlay of their own: one Compose file on their own machine, overlay.yml in lemonfiber’s configuration directory, which lemonfiber merges last, over the project it generated (ARCH-R252). Its place is fixed rather than a setting: no key names a second file or moves this one. A path recorded under the retired LEMONFIBER_OVERLAY key is not read; the doctor names it and says to move that file to overlay.yml. This is the escape hatch ADR-0021 §6 described, kept on the same terms: it is the operator taking responsibility for their own machine with their eyes open, and never a route a manifest can take on anybody’s behalf.

• It is never a plugin’s. No manifest, catalogue entry or bundle supplies one, and nothing lemonfiber installs writes to it (ARCH-R85). lemonfiber writes none of its own either: what standing beside an existing setup changes, its alternative ports, is an input the generator writes the published ports from (A5).
• It is unvetted, and said so. The doctor and every rehearsal name the overlay and each service it changes as unvetted, because nothing in it was held to the model.
• It is journalled. A change to it is recorded by content when lemonfiber next writes or starts the project, so what the machine ran is answerable afterwards.

lemonfiber also writes the stack’s own wiring for a plugin’s service, from the same declaration and by the same argument — a plugin that supplies no Compose entry supplies no proxy stanza and no dashboard entry either, and gets both written for it. The proxy reaches a service at its listens port. For a lan service:

comics.{$DOMAIN} {
    reverse_proxy plex:32400
}

- Library:
    - Plex:
        href: http://{{HOMEPAGE_VAR_LAN_HOST}}:32400
        description: Plays your library on TVs, phones and browsers

A loopback service gets no proxy stanza — that is the bundled policy holding rather than a limitation of the format. It still gets a dashboard entry, with its href rendered from the tier rather than from the LAN host: the bundled stack puts nine of them on Homepage today, Prowlarr and NZBHydra2 among them, and a plugin’s service is on the same terms as a bundled one in the same tier.

The tier decides the route and nothing else. Refusing the whole wiring for a loopback service would refuse something lemonfiber accepts, which is why a_loopback_service_may_be_given_a_dashboard_group passes and why the refusal that does exist is narrower than this paragraph once said: a loopback service given a wiring.hostname is refused, naming the service and the tier.

The data root — one setting, every data mount

The data mount is written from one operator setting, the same for every service that takes data: the lemonfiber config key DATA_ROOT (ARCH-R240). Its value says which of the two it is:

ADR-0006’s rule holds by construction: each service has one data mount and no second to declare, and the setting decides where it comes from, never how many there are. The setting is a location, not a storage mode: what that location can do is still found by making a hardlink there (C5-R2).

A relative path is read from the stack directory, and one that leaves it or names the stack directory itself is refused, naming it. The server is a host name or an address and the export an absolute path. Either is refused, naming it, where it holds a comma, whitespace or anything else that would change the mount options written. There is no overlay: a service added later takes the same mount, which a hand-kept list of the services that take data did not guarantee. The NFS server and export an operator kept for the retired NAS overlay are folded into DATA_ROOT once, at the run that first writes the generated project, journalled, and not read again.

An NFS export is not a path on this machine, so the doctor reports the storage mode as nas and says the checks that read a host path (whether a hardlink can be made, the space left, whether the location is present) are not run here rather than reporting them as passed (C5).

The networks

Every network in the project, and every service’s place on it, is derived by lemonfiber from the settled asks between capabilities, the stack’s links by name and the pass service’s one network (ARCH-R241). There is no shared default network: two services share a network only where one of the rules below joins them, so every link is one the wiring states. No manifest, first-party or third-party, names a network, a subnet or an address, and none has a field in which to.

• An ask is a network. Each settled ask is a network of its own, joining the asking service and the service the ask reaches — the adapter, or the upstream where the ask is native — with no route off the host. A link by name joins the service whose id it names: where a part has moved in place, the first-party service holding that reserved id (ARCH-R301), and never a service filling the same capability under another id (ARCH-R242).
• A hostname and a panel are asks. A service the proxy routes a hostname to asks proxy.front, and one whose dashboard panel reads it asks dashboard.show, so the proxy and the dashboard reach exactly the services they front or show.
• An adapter and its upstream are a private network. Every adapter and the service it fronts share a network nothing else joins, with no route off the host. The core reaches the adapter at its contract port, published on the loopback interface, which is the third member F14-R5 names (ARCH-R243).
• A service’s own network. A service that publishes a port, or that is not confined, is on one network of its own carrying its ports and its route off the host. Where it is confined, that network translates no address off the host, so its port answers and it cannot reach out, and a confined service publishing nothing has none.
• A service taking via has no network: it is inside its filler’s, and an ask it fills joins the service it is inside.
• The pass service and the guard. The core’s pass service, where the guard asks about a live-stream pass (ARCH-R291), is on one network, which joins it and the stream.guard filler and nothing else, with no route off the host (ARCH-R312).

So a link the stack relies on is one its wiring states. Two the shipped stack made over its shared network and never wrote down are asks: Prowlarr asks indexer.proxy of the service that gets past an indexer’s bot protection, and Bindery asks download.usenet and download.torrent of the download clients, as the other curators do.

Two addresses are fixed, because two trust decisions rest on them. The media server believes which client a request came from only where the guarded door says so, and the door believes it only where the proxy says so. So lemonfiber fixes the address of the stream.guard filler on the network of its ask of media.serve, and the addresses of it and of the proxy.front filler on the network of its ask of proxy.front, each from a subnet lemonfiber holds in which the engine assigns no other address. It tells the media server the guard’s address as the one proxy it trusts, and the guard the proxy’s (ARCH-R244).

Every network names its subnet. An engine draws a network that names none from its own address pools, and a default install holds about thirty, fewer than one stack’s asks come to. So lemonfiber gives each network a /29 of 10.80.0.0/16, chosen from its name, so that a network keeps its subnet when a plugin’s networks come or go, and none inside the two fixed subnets (ARCH-R310).

One machine runs one stack. A subnet is derived from the network’s name alone, and the two fixed subnets are the same in every project, so a second project on the machine names the subnets the first holds and the engine refuses its networks. That is a limit lemonfiber keeps rather than a fault: one machine runs one lemonfiber stack (ADR-0052).

A plugin’s service is placed by the same rules: a filler of an ask is on the network that ask derives, whatever installed it, so a stand-in is reached over exactly the networks the part it replaced was reached over and gains a route to nothing else (F9-R6). Choosing which service fills an ask moves what that ask’s network joins, so the choice regenerates the project in the same journalled change as the setting, and a choice and the reach it grants move together (ARCH-R245).

[[claim]] — the probes a core name is demonstrated by

[[claim]]
capability = "media.serve"

[[claim.probe]]
id      = "guarded"
request = { method = "GET", path = "/api/v1/series" }
expect  = { status = 401 }
fixture = "fixtures/media-serve-guarded.json"

[[claim.probe]]
id      = "catalogue"
request = { method = "GET", path = "/api/v1/series" }
expect  = { status = 200, json_has_keys = ["content", "totalElements"] }
fixture = "fixtures/media-serve-catalogue.json"

The vocabulary owns what must be shown; this owns where to ask. A capability is one contract with many claimants, each answering at a path of its own, so the published probe declares the question, the statuses that answer it, and whether a credential is needed — and the binding declares the method, the path and the recorded response. A binding that leaves a probe unbound, names one the capability does not declare, or carries an expectation weaker than the probe requires is refused naming the probe (ARCH-R109).

No service an adapter fronts is asked as the operator. lemonfiber asks such a service nothing itself: the credentials it holds for it are the ones it mints, and those reach the adapter through upstream.json and nothing else of lemonfiber’s, so a probe whose vocabulary entry says credential = "operator" has no credential to be asked with. A claim whose capability such a service provides, binding such a probe, is refused, naming the probe and the adapter. What the probe would check is checked through the adapter instead: its contract’s conformance cases ask the adapter with its key (ARCH-R302).

provides and this are a declaration and its evidence rather than two lists. A core name in provides with no claim is refused; a claim whose capability is not in provides is refused; both name the other half.

A namespaced capability gets no claim block and cannot have one. There is no published contract for it to satisfy — that is what inert means — and the plugin’s own [[proof]] entries are where it says what it can nevertheless demonstrate.

[[ask]] — what a plugin’s service asks for

[[ask]]
service    = "subfinder"        # optional where the plugin declares one service
capability = "library.curate"
each       = true               # every service that fills it, not one

The bundle’s [[wiring]] has filled_by, to and why; an ask has none of them. A link by name is the exception the bundle or the operator makes (F4-R12), and a manifest has nowhere to write one (F14-R22).

[[wiring]] — how the stack’s own services reach one service

[[wiring]]
hostname = "comics"
dashboard_group = "Library"
dashboard_description = "Comics"
dashboard_icon = "komga.png"

Six fields, and none of them names a service outside this plugin. The bundle’s [[wiring]] is the other kind: the stack’s choices of filler and its links by name between parts; this one is a plugin saying where its own entry goes, and lemonfiber writes both the route and the panel from it.

An array, and one entry per service at most. A hostname is a fact about one container rather than about a plugin, which only became visible once a plugin could declare two: a default taken from the plugin’s own id would have given two services one address. A second wiring for the same service is refused naming the service — it has one address and one panel.

A plugin that is installed and then has to be wired by hand is one the operator has to do the work lemonfiber exists to do. The bundled stack puts a household service behind Caddy and on Homepage; a plugin’s service gets the same, written by lemonfiber from what the manifest already declares — the id and port to reach it on, the tier that decides whether it is reachable at all, and the description that goes beside it.

The tier governs, not the plugin. Only lan services are proxied, because the bundled policy is that an admin surface does not get a hostname — every admin stanza in the shipped Caddyfile is commented out with what you would be accepting written next to it. A loopback service gets no route, and there is no field by which it can ask for one: a wiring giving one a hostname is refused, naming the service and the tier that decides it. That is the same reasoning as ARCH-R88: a plugin that could publish its own address could put an admin surface on the household network without touching anything C6 inspects.

A link, not a widget. The dashboard entry is an icon, a link and a description: the ones the wiring names, or <service id>.png and the description the manifest already carries. Every service with a port has one unless its wiring sets dashboard_hidden. The entry of the filler of media.serve links to where the household reaches it: through the filler of stream.guard where one runs, which then has no entry of its own. A widget reads a service’s API with a credential, which means an adapter and a captured value — a recipe, arriving with F8. A plugin gets the panel that needs nothing and waits for the one that needs something.

What a request may ask for

A request is method, path, and — where the service needs asking — accept.

request = { method = "GET", path = "/identity", accept = "application/json" }

Why there is a field at all. A service that answers XML unless a caller asks for JSON cannot satisfy a capability whose probe requires a JSON assertion, and before this there was nowhere to ask. Measured against plexinc/pms-docker@sha256:e0ab2739…, the same path in the same second:

GET /identity                          GET /identity  (Accept: application/json)
Content-Type: text/xml;charset=utf-8   Content-Type: application/json
<MediaContainer size="0" …/>           {"MediaContainer":{"size":0, …}}

Why it is one field and not a header map, which is the part worth reading twice. A probe declares who it is asked as, and credential = "none" on every guarded probe has meant what it says partly because a manifest could present nothing. A map of headers would turn that into a convention somebody has to enforce, and it could not be enforced: a service may name its credential header whatever it likes — X-Plex-Token, X-Api-Key, something nobody has seen — so no list of refused names is ever closed. One named field keeps it a property of the format instead. A probe still cannot present a credential, because there is nowhere to write one.

A recipe’s [[recipe.step]].call does carry a headers table, and the asymmetry is deliberate rather than an oversight. A recipe runs with lemonfiber’s own authority, exists in order to carry a captured value to a destination, and every flow it could produce is declared as a [[recipe.pair]] and checked before a call is made. A probe has no such analysis and gates an install.

accept is one media type: type/subtype, optionally followed by ; name=value parameters. A list is refused — which representation came back would then be the service’s choice, and a recording is of one answer. A wildcard is refused — it asks for nothing in particular, which is what a request with no accept already says and says more plainly. What a media type may carry is letters, digits and !#$%&'+-.^_`|~; anything that would have to be quoted on the wire is refused, because a value needing quoting is one a reviewer cannot read as what arrives.

[[proof]] — what must hold before it is installed

A plugin declares the checks that must hold before it is installed: each a request, or a run of the image’s own program where the service answers none, what the answer is expected to be, and the recording it is proved against. The whole of [[proof]] is on its own page.

[[contribution]] — a row in a register lemonfiber already runs

[[contribution]]
at        = "doctor.check"
id        = "komga:claimed"
title     = "Komga has an administrator, so nobody else can become one"
category  = "services"
request   = { method = "GET", path = "/api/v1/claim" }
expect    = { status = 200, json = { isClaimed = true } }
fixture   = "fixtures/api-v1-claim-claimed.json"
timeout_s = 10
why       = "An unclaimed Komga hands administrator to whoever asks first."

[[contribution]]
at     = "doctor.remedy"
id     = "komga:claim-it"
for    = "komga:claimed"
action = "Open Komga and create the administrator account"
why    = "Until somebody does, the first caller on the household network becomes it."

The fields are not enumerated here, and deliberately: the row belongs to the point and the point is published, so restating it would be a second description of a format that already has one — F10-R2’s objection, one level down. What is fixed here is that a contribution is declared in this block and nowhere else, and that it carries exactly the row its point declares.

What that buys is the property F3-R26 is written for: nothing new evaluates a contribution. The doctor already runs checks independently, bounds each one, keeps unverified distinct from pass, and carries a remedy on anything that does not pass. A contributed check is another row in that register, run on exactly those terms and attributed to its plugin wherever it appears.

Every check carries at least one remedy (F3-R34). A check that can say something is wrong and nothing about what to do has moved the work to the operator rather than done it, and C1-R2 has no exemption for a contributed finding.

The row’s service field is what a check names where the plugin declares more than one, and it is required there: the plugin’s own service is the default and has no referent once there are two. A remedy asks nothing and names nothing.

Contributing is a capability a manifest asks for by name. Each published point names the one a contribution there requires (extension-points), and a manifest carrying a contribution without asking for it is refused by naming that capability — the same rule recipe.run gets below, and for the same reason: a build that read a row it could not run and dropped it would install a plugin whose declared behaviour is wider than its actual one.

[[recipe]] — ordered calls, bounded by reading

A plugin may declare ordered calls that configure what it installed, each bounded by what it reads, and run only when asked for by name. The whole of [[recipe]] is on its own page.

[[secret]] and [[override]] — declared before they are held

A plugin declares every secret it holds, the ones lemonfiber mints for its own service included, and every bundled thing it changes, before it holds or changes either. The whole of [[secret]] and [[override]] is on its own page.

[requires] — what the plugin needs of lemonfiber

[requires]
capabilities = ["service.add", "service.health.http"]

A plugin names what it needs. lemonfiber answers from the same set GET /api/capabilities serves (ARCH-R78), and an unmet requirement is refused by naming the capability, never by naming a version (F3-R21, F6-R10).

This is the companion’s problem in a different costume, and it gets the same answer for the same reason: a plugin written a year ago against a stack it has never met keeps working for exactly as long as the things it actually uses still exist, and when it stops working the message says which thing went. A version number cannot say that, because it conflates “older” with “missing something you needed”.

Reading a declaration lemonfiber does not recognise

Unknown names are tolerated when reading an answer and refused when reading an instruction. The two rules point in opposite directions, deliberately, and conflating them opens a hole:

ARCH-R81 reads as a general forward-compatibility principle, and it is one — for answers. Applied to manifests it would mean a plugin could carry a field this lemonfiber does not implement, have it skipped, and be installed on the strength of a declaration that did not describe it.

Refusal is not the same as a parse failure, which is the distinction F4-R14 draws. An unrecognised field or value is named, alongside what was available, and it is reported with every other violation in the same pass — not raised as the first error a deserialiser happened to reach.

The published schema

The schema is generated from the types lemonfiber deserialises, published with every release, and never hand-written. This is ADR-0014’s principle applied a second time, and for its stated reason: a schema that is written is a claim about the server; a schema that is generated is a description of it.

A hand-written plugin schema would be a second description of this contract that can disagree with the parser, and the disagreement would surface as a plugin that validates in an author’s editor and is refused on an operator’s machine.

Publication is what makes authoring ordinary. A JSON Schema published at a stable location gives completion, inline validation and hover documentation in any editor that speaks it, in any language, with nothing to install and nothing to keep in step. It is a better instrument than a library for the same job, and there is only one of it.

Validation

Every violation is reported in one pass, each naming its location (F3-R22, F1-R9). This includes the faults a strict deserialiser would otherwise raise one at a time — an unknown field, an unknown enum value, a wrong type — because a third-party manifest is far likelier to carry several of them than a first-party one, and fixing a manifest one error per run is a guessing game.

A manifest that fails any of these is refused outright — never partly applied, never applied on the strength of the parts that did parse (F3-R2).

Compatibility

schema_version is a monotonic integer naming the format generation, as it is for stack.toml. The supported window is not the same, and the difference is the point.

stack.toml’s window is the current generation and one predecessor, which buys a fork’s maintainer one release cycle of overlap. That is the right trade for a fork: one person, actively tracking, who will bump. It is the wrong trade for a plugin ecosystem, where most authors are not watching and a plugin that was finished is not abandoned. A two-generation window would quietly delete the long tail of the catalogue at every second schema bump, and the operator’s experience of that is not “this plugin is old” but “my media server stopped”.

So a plugin manifest generation is supported until it is deprecated by announcement and then removed, never merely by being overtaken. In practice the format is expected to stop moving well before the pressure arrives: schema_version changes in place until the first release candidate (versioning), and everything this version leaves for later is additive by design.

Capability negotiation carries what the window does not. A manifest that still parses but asks for something that has gone is refused by naming the thing (ARCH-R90) — which is the honest failure, and a different failure from being unreadable.

Requirements

Related

• ADR-0021 — the decision this contract implements
• ADR-0048 — a proof that runs the image’s own program
• ADR-0049 — every recording taken again by the core when a pin moves
• ADR-0046 — when the environment file is filed, and what the journal keeps of a secret
• plugin-manifest-service — what a plugin runs, field by field
• stack-manifest — the vocabulary a plugin’s service is declared in, and the whole-stack manifest this is not
• bundle — the profile a first-party plugin’s services sit in, the ids it reserves, and the stack’s choices and links by name
• capability-vocabulary — the names provides may carry and the probes a [[claim]] binds
• extension-points — the points a [[contribution]] is made at and the row each one takes
• versioning — the three version identifiers, and the window this one does not share
• web-api — ARCH-R78–ARCH-R82, the capability negotiation this reuses and the tolerance rule it inverts
• F3 — what a plugin is
• F7 — what stays readable once one is installed