Base packs: agents you inherit

Staleness note, added 2026-09-08. This post documents the base pack as it shipped in core v2.3.0/v2.4.0, and it was accurate then. As of core v2.20.0 (commit 1daee5b2), the pack's pipeline_health and proposal_brief operations were converted to skills: they now live at skills/pipeline-health/SKILL.md and skills/proposal-brief/SKILL.md under packages/core/templates/base/ (the base pack's own comment header records this: "operations were converted to skills in 2.0.0"). requiresApproval is a plugin-contract concern (packages/core/src/libs/plugins/registry.ts), not a field an author sets on a skill or operation in YAML — see docs/entities/skill.md. The inheritance mechanics (extends, override-not-fork, provenance, ghost cards) are the durable part of this post; see the current shape at docs/entities/base-pack.md, where use: is now a structured map of agents:/skills:/playbooks: rather than the single-verb form shown below.

Every Vocion install so far has re-authored the same RevOps agents from scratch. A revenue front-door coordinator, a proposal specialist, the pipeline-health operation behind them — each new workspace started by copy-pasting YAML from the last one and editing it in place. Copies drift. A prompt fix or a safety tweak lands in one workspace and never reaches the others, and six months in nobody can say which fork has the good version. This release pair (v2.3.0 on 2026-08-12 and v2.4.0 on 2026-08-17) replaces the copy with inheritance: a versioned base pack that ships inside vocion-core, which a workspace activates and overrides instead of re-authoring.

What's new

Stale as of core v2.20.0 — "operations" below are now "skills"; see the note above.

• extends: core@1.0.0 in workspace.yaml. Three verbs, all in the manifest: extends pins the pack, use activates agents (use: all takes everything), disable subtracts a default. Activation is agent-rooted — naming revenue-director pulls its operations and object types transitively, so you never hand-list skills.
• The pack ships real agents. revenue-director (the workspace's front door — consults team leads, synthesizes one decision-ready picture) and proposal-writer, plus the pipeline_health and proposal_brief operations they declare. Generic skeletons: no customer teams, people, or connectors — your workspace layers those on.
• Override, don't fork. Drop a same-slug file marked extends: core and mention only what changes: scalars replace the base value, arrays take { $append: [...] } / { $remove: [...] }, and every field you don't mention is inherited unchanged. A colliding slug without the marker is a hard error — declare intent or rename.
• Provenance. Every loaded definition carries an origin — core, workspace, or merged — and the resolved pack pin folds into workspace_sha (e.g. <sha>+core@1.0.0), so "exactly what ran" still has one answer even when the workspace files didn't change.
• Approval-downgrade guard. A workspace override cannot flip a base operation's requiresApproval: true to false. Caught at load, so workspace:check fails too.
• Both layers in the drilldown. Agent and operation pages now show the inherited base file as a read-only tab tagged core next to your editable override; a purely inherited default shows the core layer alone (previously that page had nothing to render).
• Ghost cards (v2.4.0). The Agents page renders core agents you haven't activated as greyed, non-clickable "Core · not activated" cards, with an All / Activated / Not activated filter — the catalog of what the pack offers, visible from the dashboard.
• Nothing is required. Omit extends and your workspace loads byte-for-byte as before.

Why we built it

Stale as of core v2.20.0 — the approval-downgrade guard below is described against "operations" and a requiresApproval: true YAML field, both since removed from the authored shape; whether an equivalent guard exists for skills is not verified against public docs as of this note. See the note above.

A base pack is not a seed. The Meridian sample workspace is a one-shot copy into an empty org — useful for a demo, but from that moment it's a fork. The pack is a compose-at-load layer: core@1.0.0 stays maintained upstream, and a workspace moves to a new version only by bumping its own pin. Publishing core@1.1.0 never silently reaches a pinned instance, and the pin in workspace_sha means two installs on different pack versions are distinguishable in every audit row.

The approval-downgrade guard deserves its own paragraph, because inheritance creates a failure mode plain YAML never had. Vocion's safety model is drafts-only: any operation that touches the outside world — sending mail, writing a CRM record — declares requiresApproval: true and stops at a human. Once definitions merge across layers, a one-line workspace override could flip that flag on an inherited operation, and nobody reviewing the workspace diff would see the base file it was quietly disarming. So the loader refuses the downgrade outright: if the base declares an approval gate, no override can remove it, and because the pin is explicit, no pack update can rearrange gates under you without a diff you chose to take. Overrides that keep the gate merge normally.

Where to find it

• Manifest: extends / use / disable in workspace.yaml; validate with npm run workspace:check.
• Dashboard: /dashboard/agents for ghost cards and the activation filter; /dashboard/agents/<slug> for the layered drilldown with the core badge.
• Docs: the "Base packs — activate + extend" section of docs/workspace.md in vocion-core covers the full merge vocabulary and guardrails.
• Code: packages/core/src/libs/workspace/{merge,compose,loader,reader}.ts and the pack itself at packages/core/templates/base/.
• Releases: https://github.com/vocion/vocion-core/releases/tag/v2.3.0 and https://github.com/vocion/vocion-core/releases/tag/v2.4.0