Launch parity backlog

Working backlog for the launch-readiness program. It is the landing place for the capability gaps a competitive review surfaced, restated so the platform team can act on them.

What this is, and what it deliberately is not

The source is a competitive review, not a product decision. A research pass compared Ever Works against the products buyers evaluate alongside it and produced a ranked list of capabilities we do not have, or have only half of. That review, with its per-product evidence, lives outside this repository and stays there.

Every entry is written in Ever Works' own terms. A row says what this platform would do, where in this codebase it would live, and what a user of this product would see afterwards. No outside product is named, described or alluded to, and no row is attributed to whatever raised it. Nothing here can carry a competitor name into a pull request, a commit message, a spec stub or a published docs page — the only surface in Ever Works where a competitor may be named at all is a website /compare/* page, and this file is not one.

Rows are ordered by demand, highest first. The ordering carries the review's ranking, which blended how many independent reviews raised an item, how close it sits to the wedge (content and code, owned in Git, maintained autonomously), whether it makes a live page inaccurate today, and build cost against what already ships. The counts themselves are omitted deliberately — a convergence count is attribution.

Nothing here is a commitment. This file is internal working documentation. It is intentionally absent from apps/docs/sidebarsPlatform.ts, exactly like the rest of docs/internal/ and docs/specs/, so it does not publish. Promoting a row to a public roadmap entry on the website is a separate, deliberate decision — a public roadmap row is a promise, and this file is not.

Every row was re-checked against this repository before it was listed. Rows the check found already shipped were removed rather than restated as gaps; they are recorded under Checked and removed so the id gaps are not mysterious. Several rows were narrowed to the half that is genuinely still missing, and those are noted in place.

How to read a row

Field	Meaning
ID	Stable. An id is never reused or renumbered. A row that ships moves to Checked and removed rather than being deleted, so an old reference still resolves.
Status	The docs vocabulary — missing, partial, coming-soon. A partial row names the half that does not ship.
Feature spec	Self-contained and paste-safe. Drop it into a docs/specs/ stub, an issue or a pull-request description verbatim; it names no outside product and needs no context.
Suggested home	Where it would live — plugin capability, entity, API route, dashboard route, docs page. A suggestion, not a design review.
Effort	A sketch, not an estimate. S ≈ days on one surface · M ≈ weeks across a few · L ≈ a quarter, a new capability or contract · XL ≈ a sequenced chain.
User-visible outcome	What someone can do afterwards that they cannot do today. A row that cannot fill this in is not ready to be worked.

P0 — category floors and publish blockers

These either make a live compare page or docs page overstate what ships, or are table stakes in a category the product claims.

ID	Gap	Status	Feature spec (paste-safe)	Suggested home	Effort	User-visible outcome
G-13	Long-form post and landing-copy generators	missing	Add first-class content generators for the blog, website and landing-page work kinds beside the existing directory-item generator. The blog generator reads the topic prompt, cadence and posts-per-run already declared in .works/works.yml, researches an angle with the configured search and extraction providers, produces an outline, writes a full long-form post with cited sources and inline imagery where a media capability is installed, and commits it to posts/ under the work's normal merge policy. The landing-copy generator writes hero, feature, pricing and FAQ copy into the site configuration file the template reads. Both ride the item pipeline's scheduler, retries and auto-pause semantics, respect the work's style, brand and persona knowledge-base documents, and stay observable in the session and steering surfaces.	New generators beside packages/agent/src/generators/{data-generator,markdown-generator,website-generator}; a post content shape in the data-repo contract; consumes generation.cadence / topics_prompt / posts_per_run; surfaces on the existing Posts and Pages tabs; new docs/features/post-generation.md.	L — one pipeline stage per kind plus a content shape; no new capability category	A blog or landing-page Work writes real, cited, publishable copy on its own cadence instead of directory-shaped items.
G-01	In-dashboard live preview of a Work's site	missing	Render a running preview of a Work's generated site inside the dashboard, on the Work workspace, before and independently of a production deploy. The preview serves an ephemeral build of the current branch — the Task branch when one is selected, otherwise the default branch — updates as agent runs write files, and exposes a shareable, optionally password-protected URL scoped to Work members. It must degrade honestly: show build output and the failing step rather than a blank frame, and say plainly when a preview is still warming. Build it as a capability other features consume rather than as a one-off screen, because click-to-edit, browser-driven acceptance checks and per-branch review all sit on top of it.	New preview plugin capability category beside the existing deployment and workspace categories, with a first provider over the ephemeral job sandbox packages/plugins/sandbox-workspace already creates; GET /api/works/:id/preview returning status plus URL; dashboard route works/[id]/preview; new docs/features/work-preview.md.	L — new capability category, one provider, one dashboard route	Someone watches the site they described take shape while the agent works, instead of waiting for a deploy to find out what happened.
G-02	Visual click-to-select editing that commits	missing	On top of the live preview, let a user click an element, see what backs it — a content-item field, a Markdown block, a site-config value or a theme token — and edit it in place: text inline, styling through the template's declared design tokens, or by describing the change in natural language for an agent to apply. Every accepted edit becomes a normal commit or pull request on the owning repository under the Work's merge policy, so Git-native ownership is strengthened rather than bypassed. Scope the first increment deliberately to text and token edits on template-declared regions, with an explicit "this element is not editable here, edit it in the repository" state for everything else. A content-editor role should be able to use the surface without repository write access.	Template contract addition — stable data-ew-* markers emitted by the website templates; editor overlay in apps/web/src/components/works/detail/preview/; POST /api/works/:id/preview/edits producing a commit or PR through GitFacadeService; new docs/features/visual-editing.md.	L — template contract change plus an overlay; depends on G-01	A non-developer fixes a headline by clicking it, and the fix still arrives as a reviewable commit.
G-10	Store builder — the full dependency chain	missing (chain)	Make store a real work kind end to end rather than an inert chip: the kind itself, a commerce storefront template, a merchandisable product model distinct from a directory item, a payment capability, order and customer operations, a bring-your-own commerce-backend connector, commerce-shaped research and copy generation, and commerce agent presets. The eight sub-items below are strictly sequenced and nothing downstream can start until the kind exists. One deliberate constraint runs through all of them: checkout, tax and fraud are adopted through a connected commerce backend and never rebuilt here, because the differentiator is catalog research and content, not payment rails.	packages/contracts/src/domain/work-kind.ts plus work-capabilities.ts; new product entity in packages/agent/src/entities/; new plugin categories payment and commerce; docs/features/store-builder.md (today "coming soon") becomes the feature page.	XL — eight sequenced sub-items and two new capability categories	Describing a shop produces a shop that can take money, staffed by agents that keep the catalog current.
G-09	Enterprise identity and enforced org roles	missing (SSO) / partial (RBAC)	Two distinct pieces, both required before any procurement conversation. First, enforced organization-level authorization: today the organization membership role column holds a single value and is explicitly display-only, and the write-side admin check resolves to the same check as reading, so every member can invite, revoke, remove and edit organization settings. Give organizations a real role enum with an enforced permission matrix, mirroring the Work-level roles that already work. Second, enterprise single sign-on: SAML 2.0 and OIDC as identity providers, optional SCIM provisioning with group-to-role mapping, and an exportable audit log with a streaming option to an external security endpoint. Until the first lands no page may claim organization RBAC; until the second lands no page may claim SSO in any form.	organization_member.role enum plus a policy service beside packages/agent/src/policy/merge-policy.service.ts; new auth strategies in apps/api/src/auth/; apps/api/src/activity-log gains an export and a delivery subscription; docs/features/organizations.md plus a new docs/features/enterprise-identity.md.	L — auth strategies plus enforcement on every organization write path	An organization hands out real admin and member roles, and signs in through its own identity provider.
G-07	SEO and GEO — the measure-and-act half	partial (emit ships, audit missing)	The emit half already ships and is genuinely strong: structured data across six schema types, canonicals, hreflang across 21 locales, a per-locale sitemap, an AI-crawler robots policy, RSS/Atom/JSON feeds, /llms.txt, /llms-full.txt and a Markdown twin of every public page. What is missing is everything downstream of publishing. Add (1) a per-Work audit surface that crawls the deployed site after every deploy, scores it and lists prioritised findings — missing or duplicate titles and descriptions, missing alt text, broken internal links, heading order, invalid structured data, sitemap health; (2) per-page metadata editing from that surface with a one-click "have an agent fix this" that opens a normal pull request; and (3) an answer-engine visibility metric source that periodically asks a set of answer engines the audience's questions and records whether the site is cited, surfaced as a Goal metric so a scheduled agent can act on it. The agent-side audit skill already exists and should be reused, not rebuilt.	New quality-gate check kind site-audit plus a site-audit plugin capability; a metric provider plugin for answer-engine visibility feeding docs/features/goals.md; dashboard route works/[id]/seo; new docs/features/seo-audit.md.	M — the audit skill exists; this is the crawl, the surface and the loop	A Work reports its own search and answer-engine health, and an agent fixes what it finds without being asked.
G-06	Media generation as a plugin capability	missing	Add an image-generation plugin capability — and, behind the same contract, optional video and text-to-speech — so content pipelines and agents can produce original imagery rather than only capturing screenshots of third-party pages. Minimum viable scope: generate a hero image, an Open Graph image, per-item or per-post illustration and a logo mark from a text prompt plus the work's brand knowledge-base document, write the result into the data repository's assets folder as a normal commit, and emit alt text alongside every asset. Cost is metered through the existing usage ledger and gated by the existing budget caps. A second increment adds targeted editing — replace a region, change in-image text — and exposes the capability as an agent tool so it is reachable from a Task.	New image-generation category beside the existing screenshot category in packages/plugin/src; providers under packages/plugins/; agent tool registered in packages/agent/src/agents/agent-tool.service.ts; new docs/plugin-system/image-generation-plugins.md.	M — the cheapest high-demand row in the document	Generated sites and posts ship with their own artwork instead of placeholders or borrowed screenshots.
G-16	Lead capture — form, inbox, first reply, CRM	missing	Give generated sites a first-class lead pipeline. Add a form block the templates can place on listing, category and landing pages; route each submission into a platform-side leads inbox on the owning Work with search, filter, CSV export and per-lead status; let a nominated agent draft a first reply, held for approval by default, using the Work's knowledge base; forward submissions to an email address, a webhook or one of the existing CRM connector plugins; and accept inbound leads captured elsewhere through a signed endpoint. For directory works, associate a lead with the listing it came from so an owner-claim flow can later hand leads to a verified owner. Bot protection must extend to the new endpoint from day one.	New lead entity in packages/agent/src/entities/; POST /api/works/:id/leads (public, rate-limited, captcha-protected) and GET /api/works/:id/leads; dashboard route works/[id]/leads; reuses the existing CRM connector plugins and the inbound-email path; new docs/features/leads.md.	M — one entity, two routes, one template block	A generated site turns a visitor into a tracked lead with a drafted reply waiting for approval.
G-34	Owner claim and verification for listings	missing	Let a real business owner take over a listing the platform researched and wrote. A visitor requests a claim from the listing page, proves ownership by one of several methods — a matching email domain, a DNS TXT record, a phone or SMS code — and on approval gains an owner role scoped to that single item: they may edit its fields, respond to reviews and see the leads it generated. Claims are moderated in the generated site's admin area and land on the data repository as a normal reviewable change, so nothing bypasses the merge policy. Support an invite-to-claim email for imported or researched listings, an optional paid claim through the template's existing checkout, and a verified badge on claimed entries.	New listing_claim entity; template routes /claim/:itemId and /admin/claims; item-scoped role in the generated site's RBAC; reuses the existing visitor accounts, moderation and checkout; new docs/features/listing-claims.md.	M — verification methods plus one moderation surface	An AI-seeded directory becomes a directory that real businesses join, verify into and pay for.
G-14	Publish into a CMS the customer already runs	missing	Add a publishing plugin capability so a Work can maintain a site the platform did not generate. A publishing target is configured on the Work, receives generated posts, pages or listings over the destination's API with the same content model the data repository holds, maps taxonomy and media, records the remote identifier so later runs update rather than duplicate, and reports failures into the run's activity. Support at least one self-hosted and one hosted destination in the first increment. The Work keeps its Git data repository as the source of truth and the external site becomes an additional deploy target rather than a replacement, which preserves the ownership story while removing the migration barrier that today excludes every prospect who will not move their existing site.	New publishing category beside deployment; providers under packages/plugins/; wired into the Work's Deploy tab as an additional target; new docs/features/external-publishing.md.	M — one capability, two providers, one tab	A prospect who will not move their existing site can still buy the product and point it at the site they have.
G-11	Backend capabilities beyond the fixed schema	partial	The directory template already ships end-user authentication, a relational database, RBAC and checkout — but on a fixed listing schema, and the minimal template ships none of it. Close both halves. First, make the backend layer available as declarable template add-ons so a website, landing-page or blog work can opt into accounts, database-backed forms, file uploads and transactional email without switching to the directory template. Second, let a work declare additional typed entities in its configuration — fields, references and per-role read/write rules — which the template provisions and renders, so a work can be a members area, a tracker or a portal rather than only the fixed listing shape. Provisioning uses the database and storage plugins that already exist for the runtime, extended to serve the generated site.	spec.entities[] in the works.yml v2 schema; migration runner in the website generator; reuses the existing database, object-storage and transactional-email plugins; extends docs/features/generated-site.md and docs/features/website-templates.md.	L — a schema contract plus provisioning across every template	"Build me a members portal" produces a members portal, not a listing site wearing the wrong shape.
G-24	Ungate managed hosting and the free subdomain	partial	Managed hosting itself is shipped and good — a public subdomain with its DNS record, HTTPS at the ingress, a database per Work, optional managed Git and the cluster, with no kubeconfig, registry or DNS zone for the user to own. The gap is availability. Make it the default path for every account rather than an operator-flagged one; raise or remove the three-active-Works-per-user cap; allow an existing Work to switch onto it from the Deploy tab rather than only at creation; and provide a zero-configuration data path so the default template does not require the user to arrange a database before the site can render. Add password protection for unpublished or staging sites while doing this. The goal is a stated, testable promise.	Default DEPLOY_EVER_WORKS_ENABLED on; raise EVER_WORKS_DEPLOY_MAX_WORKS_PER_USER (default 3 today); enable K8S_MANAGED_SUBDOMAIN by default; allow a provider change on PATCH /api/works/:id, which is rejected today; updates docs/features/managed-hosting.md.	S — mostly defaults, plus one rejected transition to allow	Sign up, describe a site, get a live URL — with no third-party account anywhere in the critical path.
G-17	Publish the desktop app	partial	The application exists, both modes work, and CI already packages Windows, macOS and Linux installers as workflow artifacts. What is missing is distribution: a public download page, signed installers, a release job that publishes them, and an auto-update channel. Ship those, then reconcile the surfaces that currently state its status three different ways so a reader gets one answer. Publish an Intel/x64 macOS build and a Linux installer alongside the Apple-silicon build while doing it, so platform coverage is broad rather than convenient.	.github/workflows/desktop-build.yml gains a release job — it uploads artifacts only today; a /downloads page on the website; docs/features/desktop-app.md and docs/guides/desktop-app.md reconciled to one status line.	S — signing and a release job; the build already exists	Someone downloads and installs the desktop app instead of being told to build it or dig a 14-day CI artifact out of a workflow run.
G-04	Version timeline with one-click restore	partial	Give every Work a version timeline in the dashboard: each agent run, chat-driven edit and scheduled regeneration appears as an entry with what changed, a per-entry diff, the cost it incurred and an optional bookmark with a note. One click restores the Work to any entry — additively, by reverting forward rather than rewriting history — covering the data repository, the website repository and the run context together, with an explicit statement of what a restore does and does not roll back, such as a completed deploy or an external publish. Content history already exists for items; this extends the same idea to code and to whole runs.	Extends docs/features/work-changelog.md and the Sessions list; POST /api/works/:id/restore producing revert commits through GitFacadeService; dashboard route works/[id]/history.	M — one route plus a timeline surface over data that already exists	"The agent changed something I did not want" becomes a button instead of a Git operation.
G-12	Per-Work visitor analytics in the dashboard	missing	Add an analytics view on the Work workspace showing sessions, page views, top pages, referrers including referrals from AI answer surfaces, devices, countries and conversions over time, fed by the metrics plugins that already exist and by the analytics the generated site already emits. Wire an analytics provider automatically at deploy time so the metric tiles that currently read "connect analytics to see this" have data on day one. The strategic point is not the chart: it is closing the loop so a scheduled agent can read what happened and change what it does next.	Dashboard route works/[id]/analytics; reuses the existing metrics plugins and docs/features/goals.md; an auto-provisioning step in the website generator; new docs/features/work-analytics.md.	M — one route plus deploy-time provisioning	An owner sees what the site actually did this week, and the agent maintaining it reads the same numbers.

G-10 sub-items, in build order

Nothing downstream may start until G-10a lands.

ID	Sub-item	Spec	Effort
G-10a	store as a real work kind	Add store to the work-kind vocabulary, normalizeWorkKind() and the per-kind capability registry, and flip its feature flag, so the currently inert chip becomes a selectable kind with its own tabs and metric tiles.	S
G-10b	Commerce storefront template	Register at least one commerce template in the website-template catalogue that renders product, collection and product-detail routes plus a cart, alongside the existing content templates, and make it the default a store work resolves to.	M
G-10c	Product catalog data model	Extend the content model with a merchandisable product entity distinct from a directory item — SKU, variants, options, price and currency, stock level, media set, shipping class, supplier — with the generator, importer and dashboard surfaces to populate it.	M
G-10d	Payment / checkout plugin capability	Introduce a payment plugin capability with at least one real provider so a generated storefront can take money, keeping the existing read-only revenue-metrics plugin separate and unchanged.	M
G-10e	Order and customer operations	Order and customer records with refunds and a support inbox tied to an order — deliberately delegated to the connected commerce backend rather than built natively wherever that backend can serve it.	M
G-10f	Bring-your-own commerce backend	A commerce plugin capability that connects a store work to a commerce backend the customer already owns or that the platform provisions, and publishes the generated catalog into it over that backend's API, so checkout, tax and fraud are adopted and never rebuilt.	M
G-10g	Catalog research, copy and upkeep	Extend the research and item-generation pipeline from listing discovery to merchandisable product discovery with supplier, cost and margin signals recorded in the knowledge base; add commerce-shaped prompts for product titles, descriptions, collection copy and commerce SEO; and add scheduled tasks that add, refresh and retire catalog entries.	M
G-10h	Commerce agent presets	Ship merchandiser, copywriter and analyst agent presets in the agents catalogue so a store work is staffed on creation, reusing the preset mechanism the go-to-market presets already prove.	S

P1 — real gaps with a clear buyer, one step behind the floor

ID	Gap	Status	Feature spec (paste-safe)	Suggested home	Effort	User-visible outcome
G-14b	Existing-post and published-page refresh loop	partial	Score already-published posts and pages for decay — dated statistics, dead outbound links, superseded claims, drifted rankings, thin sections — and queue targeted rewrites rather than re-running the whole generation pipeline. A refresh run reads the live page, the original sources and the work's knowledge base, edits the prose in place, and opens a pull request naming what changed and why. Cadence, the maximum number of refreshes per run and a minimum-age threshold are declared per Work alongside the existing schedule settings. The scheduler, the quality gates and the merge policy needed to do this safely all already exist.	New pipeline step in the content generator; a refresh block in the works.yml generation spec; extends docs/features/scheduled-updates.md and docs/features/item-source-validation.md; new docs/features/content-refresh.md.	M — one pipeline step over existing scheduling	A site published a year ago keeps getting more accurate on its own instead of quietly rotting.
G-03	In-app editor for posts, pages and repo files	missing	Provide a syntax-highlighted editor inside the dashboard for a Work's Markdown content and, behind an explicit "advanced" affordance, for its repository files — with a diff view against the branch head, per-file save producing a commit or pull request under the merge policy, and a preview pane. Non-technical users get a rich Markdown post editor with live preview; developers get file editing without cloning. Pair it with the pull-request tab so an agent's diff can be read and amended in place rather than on a Git host.	An editor component in apps/web/src/components/works/detail/editor/ (no editor dependency exists in apps/web/package.json today); GET/PUT /api/works/:id/files; renders diffs on the existing works/[id]/pull-requests route; new docs/features/in-app-editor.md.	M — one component, two routes, one diff renderer	A typo in a generated post is fixed in the browser instead of in a clone.
G-05	Per-branch preview URL and a staging environment	partial	Once a preview capability exists, give every isolated Task branch its own reachable, optionally password-protected preview URL, surfaced on the Task, on the pull request and in the notification announcing the run finished — so review happens against a running site rather than a diff. Add a persistent staging target per Work that a set of branches can be promoted into before production, and a promote step that runs the quality gates against the staging build. The deployment plugin contract already declares an optional preview URL field that nothing populates; this makes it real end to end.	Populate previewUrl on the deployment capability interface; docs/features/task-isolation.md gains a preview panel; works/[id]/tasks/[taskId] shows the link; new docs/features/preview-environments.md.	M — depends on G-01; the contract field already exists	A reviewer clicks a link on the pull request and sees the change running, rather than reading a diff.
G-08	Security scan as a first-class quality gate	partial	Ship scanning as a bundled gate kind rather than something each user wires as a custom shell command: a dependency and CVE audit of the changed lockfiles, static analysis of agent-changed files, secret detection, and — for works with a database — schema and access-rule linting. Findings attach to the Task with severity, file and line, and an administrator can set a policy that blocks the deploy on critical findings. Because gates already send red work back to the agent rather than to the user, the scan becomes automatic remediation rather than a report. A second increment adds an on-demand scan button for a Work between runs.	New check kinds security and deps in packages/contracts/src/tasks/task-gates.types.ts (today: build, test, lint, typecheck, custom); a security-scan plugin capability with a first provider; a policy row alongside docs/features/merge-policy.md; extends docs/features/quality-gates.md.	M — two gate kinds, one capability, one provider	A vulnerable dependency an agent introduced is caught and fixed by the agent before the branch can land.
G-15	Create a Work from a URL, a repo, or an export	partial	Widen work creation beyond the current four import types. Add (1) from a URL — scrape a site with the extraction plugins that already ship, derive structure, copy and brand tokens, and seed a landing-page or website Work from it; (2) from an arbitrary repository — point at any existing website repo, detect the stack, write an agent-rules file and let agents maintain it thereafter; and (3) from a publishing export — accept archives from the common self-hosted and hosted publishing platforms plus generic RSS, carrying Markdown bodies, so a writer with an existing audience moves in without re-creating archives by hand. Each path lands as a normal import source with the same preview-and-confirm step the wizard already uses.	Extend IMPORT_SOURCE_TYPES in packages/contracts/src/api/work/import-source.dto.ts (today data_repo, awesome_readme, link_existing, works_config); extends packages/agent/src/services/work-import.service.ts; reuses the shipped extraction plugins; updates docs/features/work-import.md.	M — three importers over one existing wizard	Someone with a site or an archive already can start from it instead of starting from nothing.
G-18	Subscriber model and campaign sending	partial	Two layers. First a subscriber model: platform-side subscriber records with tags, custom fields, segments, consent state and source, shared across a Work's generated site and any sending, plus CSV import and export so an existing list can move in and out. Then campaigns: compose an issue from published posts or from an agent-written digest, target a segment, schedule it, send through the email provider plugins that already back agent mailboxes, and report opens, clicks and unsubscribes. Keep the human gate — an agent may draft and schedule, a person approves before anything reaches an audience.	New subscriber and campaign_send entities; apps/api/src/campaigns/; dashboard route works/[id]/audience; reuses the shipped email-provider and notification-channel plugins; new docs/features/audience-and-campaigns.md.	L — two entities, a sending pipeline and an approval gate	A publication built here owns its list and can actually mail it, instead of capturing addresses that go nowhere.
G-19	Brand tokens and a cross-Work design system	missing	Capture colours, typography, spacing, logo and imagery direction as a structured, versioned brand token set that lives on the organization or the Work, is applied to every template the Work uses, is consumed by agents as structured data rather than prose, and is editable from the dashboard. Seed the token set three ways: from a brand knowledge-base document, from a URL, or from an imported design file. Templates declare which tokens they honour; agents may propose token changes as a normal reviewable change. This turns theming from "edit theme.css in the repository" into a first-class object shared across a portfolio of Works.	A brand_tokens shape in the works.yml branding block and at organization scope; a template contract addition; a dashboard card under Work settings; new docs/features/brand-tokens.md.	M — a schema plus template adoption	Every Work an organization owns looks like the same company without anyone editing CSS.
G-20	Git providers beyond GitHub	missing	Implement the git-provider capability for GitLab, Gitea and Forgejo alongside GitHub, covering repository creation, push, pull-request creation and review, and webhook ingestion, so self-hosters are not forced onto one vendor. The abstraction already exists — this is filling it in. Reconcile the documentation at the same time: one page states GitHub is the only implemented provider while two others present GitLab as connectable, which is a live contradiction as well as a capability gap.	New plugins under packages/plugins/ in the existing git-provider category; updates docs/features/git-operations.md, docs/features/creating-a-work.md and docs/features/onboarding.md.	M — three providers against an existing interface	A self-hoster keeps their own Git host instead of being told which one to use.
G-21	Multi-locale content, not just multi-locale chrome	partial	Site chrome, URL routing, browser detection, a language switcher, RTL rendering, hreflang alternates and per-locale sitemaps already ship across 21 locales. Add the layer above: translate or natively generate the work's own content items and posts per active locale, localise slugs and per-locale assets, keep translations in sync when the source changes, and let a Work declare which locales it publishes. Translation is a pipeline step with its own cost accounting and its own gate, so a bad translation fails like any other agent output.	locales[] in the works.yml spec; per-locale content paths in the data repository; a translation step in the content generator; extends docs/features/generated-site.md.	M — one pipeline step plus a content-path convention	A site actually reads in the languages its language switcher offers.
G-22	Public gallery, vertical presets and remix	partial	Three connected additions. (1) Vertical presets — register opinionated starting configurations for the verticals people actually build (job board, events, real estate, local business, restaurant, portfolio, agency), each pre-setting the field schema, filters, homepage sections and knowledge-base seed, so a vertical site starts configured rather than generic. (2) A public gallery — a browsable catalogue of Works and templates with live previews, filterable by kind and vertical. (3) Remix — one action that forks a gallery entry into the viewer's account including its template, taxonomy and knowledge-base seed, plus a "save this Work as a template" action so a proven Work becomes a starting point for teammates.	Extends apps/api/src/template-catalog and the Git-backed catalogue repos; a public gallery route on the website; POST /api/works/:id/save-as-template; updates docs/features/{work-templates,website-templates,work-blueprints}.md.	L — a catalogue surface, a fork path and seven presets	A new user starts from something that already looks like their business instead of a blank generic site.
G-25	Runtime-error and browser-driven acceptance loop	partial	Feed real failure signals back into the agent loop instead of only exit codes. Capture build errors, dev-server errors, browser console errors and failing routes from a running preview, plus post-deploy synthetic checks on the live URL, and route them into the same gate-retry cycle that already sends red work back to the agent. Add a browser gate kind where an agent opens the preview in a headless browser, walks declared acceptance flows and attaches before/after screenshots and a recording to the run report beside the diff. Narrowed on re-check: the browser execution primitive is further along than the review assumed — the browser-automation plugin ships with a default-deny host allowlist and the fleet worker already registers a browser-check job kind that drives a real browser against a URL. What is missing is the gate wiring: acceptance check kinds are still build, test, lint, typecheck and custom only.	New gate check kind browser consuming packages/plugins/browser-automation and the existing browser-check node executor; an error-capture hook in the preview capability (G-01); extends docs/features/quality-gates.md; new docs/features/acceptance-checks.md.	M — the execution half exists; this is the gate kind and the capture hook	An agent sees the page it broke and fixes it in the same run, instead of shipping a green exit code over a blank screen.
G-26	Runtime per-tool consent during a live run	partial	Layer an in-flight consent prompt on top of the existing static permission flags and tool-grant matrix: while a run is executing, a tool call that is not pre-approved pauses the run and asks, with allow once, allow always for this agent and never choices that write back into the grant matrix, and with destructive operations always confirming regardless of a standing always. The prompt appears in the session view and in the operator inbox so it is answerable from either. This complements — never replaces — the pre-run grant lattice, which stays the coarse control.	Extends packages/agent/src/agents/agent-tool.service.ts and the awaiting-input path in docs/features/sessions-and-steering.md; consent rows persist into the existing tool-grant matrix; extends docs/features/agent-capabilities.md.	M — a pause-and-ask path through an existing grant model	An operator can let an agent run wide without pre-authorising every tool it might reach for.
G-31	Experiments — variants, results, and an agent that reads them	missing	Add an experiment as a first-class object: hypothesis, variants (a headline, a hero, a section order, a product arrangement), traffic split, duration, a success metric drawn from the existing metric providers, and a recorded result. An agent may propose an experiment, the platform serves the variants through the deployed site, results are read back automatically, and the winning variant is applied as a normal commit while the finding is written into the work's knowledge base as a decision so the next run inherits it. The read-back is the point: the runtime learns from the result rather than reporting it.	New experiment entity; variant rendering in the templates; reuses the metric providers behind docs/features/goals.md and docs/features/memory-decisions.md; dashboard route works/[id]/experiments; new docs/features/experiments.md.	L — an entity, template variant serving and a read-back loop	The site tests its own copy and keeps what won, without anyone reading a dashboard.
G-32	Scheduled external data sources	partial	Let a Work declare recurring external sources that the scheduler polls, deduplicates against existing content and routes through the normal enrichment and quality gates: a spreadsheet with two-way sync, a CSV URL, an RSS or Atom feed, a sitemap, a places or business data provider, or a partner API. Column mapping reuses the wizard the one-shot importer already has. This converts the importer from a migration tool into a living data pipeline. Naming note: do not call the new capability data-sync — apps/api/src/data-sync/ is the shipped data-repository instant-sync module and the name is taken. Use source-feed or similar.	New plugin capability (not named data-sync) distinct from the existing one-shot data-source; typed kinds on sources[] in the works.yml schema; extends docs/features/item-import-export.md and docs/features/scheduled-updates.md.	M — one capability plus scheduler wiring	A directory keeps itself current from the feeds its operator already has, instead of being re-imported by hand.
G-35	Directory depth — geo, nested taxonomy, typed fields	partial	Three things a serious directory needs that the current model cannot express. (1) Radius and distance — a radius filter with a unit toggle, sort by distance and a browser-geolocation "near me" entry point, backed by a first-class location field; without it a local-business directory cannot answer its primary query. (2) Nested taxonomy — parent/child categories flowing through submission forms, filters and navigation, plus a browsable country/region/city hierarchy distinct from free-form tags. (3) A typed field designer — a per-Work schema builder covering text, number, select, multiselect, date, time, phone, URL, file and repeater with conditional-logic rules, where one definition drives the submit form, the detail rendering and the search filters.	A location typed field and a geo index in the template's data layer; parentId on category; a field-designer card under Work settings writing item_fields in works.yml; updates docs/features/taxonomy-system.md and docs/features/generated-site.md.	L — three independent surfaces on the template data layer	A local directory answers "what is near me", and a niche schema is built in the UI instead of hand-edited YAML.
G-36	Listing monetisation lifecycle	partial	The recurring-revenue mechanics of a listing business, distinct from the site-wide plans that already ship. Let the operator define membership tiers and prices with monthly and annual intervals, proration on plan change, failed-payment retry with dunning email, and per-plan submission fields. Add per-listing expiry dates with automated renewal reminders and a renew-and-pay flow, pay-per-submit pricing, downloadable invoices, discount codes applied at checkout, and optionally masked contact details a business unlocks with prepaid credits. Everything rides the checkout abstraction the template already has across four payment providers.	A per-Work plan catalogue instead of fixed constants; listing_subscription and invoice shapes in the template data layer; extends the monetisation section of docs/features/generated-site.md; pairs with G-34.	M — configuration and lifecycle over an existing checkout	A directory operator sets their own prices and gets paid again next year without chasing anyone.
G-45	Local execution — billing posture and packaging	partial (narrowed)	Narrowed on re-check: most of this shipped. The node worker host (lease → execute → report), the agent-task and acceptance-checks executors, the fleet job runtime, per-Agent node affinity, per-scope execution preferences and a local model-CLI process launcher all exist, and a node already reads the operator's own coding-CLI credential names from its own environment so the value never leaves the machine. What remains is the commercial half: a billing posture in which a run executed on the customer's own machine and their own coding subscription consumes no platform credits and says so on the invoice; a pricing line and a named mode in the product rather than a settings combination; and the documentation page that states the mode, its limits and what still runs on the platform.	Credit-exemption rule beside docs/features/credits-and-billing.md; a named mode surfaced in Settings over the existing fleet execution preference; new docs/features/local-execution.md describing what does and does not run locally.	S — a billing rule and a packaging decision, not a runtime build	"Running ten agents costs what one costs" becomes a true, stated, purchasable mode.
G-48	Keyword research, grounded briefs, content calendar	missing	Turn a topic into a ranked, deduplicated plan before anything is written. Add a keyword-data capability supplying volume, difficulty and related terms; cluster candidates into topics; and produce a dated content calendar per Work that the scheduler consumes, so recurring runs write what has a chance of ranking instead of re-running the same prompt. Before each piece, build a brief: read the top-ranking results for the target query, extract entities, related terms and competing outlines, and present an editable outline for approval. The ten shipped search providers supply the results half; the keyword-metrics half is a new capability.	New keyword-research plugin capability; a content_plan entity; a brief-building step in the content pipeline; dashboard route works/[id]/plan; new docs/features/content-planning.md.	M — one capability, one entity, one pipeline stage	Scheduled writing targets queries that can rank instead of repeating one prompt forever.
G-49	Automatic internal linking across the corpus	missing	A scheduled pass that maintains the internal link graph of a Work: new content links into existing content, older content gains links to newer relevant pages, anchor text is varied and relevant, orphan pages are surfaced and fixed, and every change lands as a normal reviewable commit. Run it as a maintenance task on the existing cadence rather than as part of each write, so link density compounds as the site grows. The audit half already exists in the shipped SEO-audit skill, which detects internal-linking and orphan-page problems; this adds the repair half.	New maintenance pipeline step; reuses the shipped audit skill's orphan and coverage detection; extends docs/features/scheduled-updates.md.	S — one maintenance step over an existing detector	A growing site links itself together instead of accumulating orphan pages.
G-51	Search console ingestion, rank tracking, indexing	missing	Connect the search console for a Work's verified domain and ingest impressions, clicks, average position and query data per URL; track positions for the Work's target terms over time; and submit newly published or materially updated URLs for indexing on publish. Surface the data as metric tiles and as Goal metrics so a scheduled agent can target striking-distance queries and decaying pages in the refresh loop. Indexing submission on its own is small and closes the loop between publishing and being found.	New metrics plugin in packages/plugins/ for the search console; an indexing step in the deploy pipeline; feeds docs/features/goals.md; extends the analytics surface from G-12.	M — one metrics plugin plus a deploy step	An agent can act on what the site actually ranks for, not on what it guessed it would.
G-52	Feature parity across the website templates	partial	The directory template carries newsletter capture, comments with ratings, feeds, llms.txt, Markdown page twins, structured data across six schema types, 21 locales and checkout. The general-purpose templates that website, landing-page and blog Works actually default to document none of that. Either (a) bring the shared surface — feeds, llms.txt and twins, structured data, newsletter capture, comments — into the general templates as declarable features, or (b) document precisely what each template emits and default blog Works to whichever template carries the blog surface. Do not ship a claim on any page for a capability only one of four templates has.	A shared template feature contract in the website-template registry; updates docs/features/website-templates.md and docs/features/generated-site.md.	M — a feature contract plus adoption in three templates	What a Work gets no longer depends on which template it silently resolved to.
G-61	Cost observability — trace, attribution, estimate	partial	Budgets already stop spend before it happens. Make the spending legible. Add (1) a per-tool-call trace — caller, agent, tool, inputs, outputs, outcome, timestamp, duration, with p50/p95 latency per tool — so a failing run can be opened and read; (2) per-step cost attribution inside a run, visible live in the session view and rolled up per produced artifact, so "what did this post cost" has an answer; (3) a pre-run estimate shown before execution starts, with model tokens separated from compute time; and (4) per-member spend caps with selectable daily, weekly or monthly reset windows, since the account cap is monthly-only today. Publish a pass-through rate card alongside it.	tool_call records beside the usage ledger; extends docs/features/sessions-and-steering.md, docs/features/budgets-and-usage.md and docs/features/credits-and-billing.md; a per-member cap on the organization member row.	M — one record type plus three surfaces	A buyer can answer "what will this cost, and what did it cost" before and after the run.
G-62	Multi-model review panel for agent output	partial	Where a gate needs judgement rather than an exit code, dispatch the same diff or task result to two or more models from different providers in parallel, tag each finding as consensus or contested, and require the run to address contested findings before it may land. Add an in-turn variant: a retry verdict injects the critique back into the same conversation so the agent self-corrects before the run ends, rather than failing and starting a fresh attempt. Both are provider-agnostic and ride the providers already installed. The gate judge makes exactly one model call today.	Extends packages/agent/src/tasks-domain/task-gate-judge.service.ts (a single askJson call today); new verdicts RETRY and ESCALATE in packages/contracts/src/tasks/task-gates.types.ts; extends docs/features/quality-gates.md.	M — a fan-out around one existing service call	Judgement gates stop inheriting one model's blind spot.
G-63	Agent eval harness and auto-computed scorecards	partial	Score an Agent against a fixed set of scenarios and keep results over time, so a change to a prompt, a model or a skill is judged on evidence rather than anecdote. A scenario declares inputs, a rubric and expected artifacts; a run produces a scored result stored against the agent and the scenario; a regression is surfaced before the change reaches production work. Feed the same signal into the existing scorecards so their current values update themselves from run outcomes, task transitions, merged pull requests and gate results, instead of requiring a human to type the number.	New packages/agent-eval/ package; an agent_eval_run entity; feeds docs/features/agent-scorecards.md; new docs/features/agent-evals.md.	L — a new package plus a scoring contract	Agent scorecards mean something, because the numbers come from what the agent actually did.
G-64	Stalled-run watchdog with recovery actions	partial	Detect an agent that stopped for the wrong reason — misread a blocker, claimed completion without evidence, gave up on a recoverable error, or entered a retry loop — and either accept the stop or restore a live path, rather than letting the task tree go quiet behind a blunt timeout. The watchdog reads the run's evidence, records its verdict, and takes a bounded recovery action: re-dispatch with the critique attached, escalate to the operator inbox, or close the task with a reason. Apply the same idea to schedules — pause a recurring schedule that keeps failing over a rolling window, mirroring the per-Agent auto-pause that already exists.	Extends packages/agent/src/agents/agent-run-sweeper.service.ts, which today only marks over-long runs failed; emits Activity entries and an inbox item; extends docs/features/scheduled-updates.md and docs/features/autonomous-operation.md.	M — verdict logic plus three bounded recovery actions	Overnight autonomy stops silently going quiet; something notices and either recovers or asks.
G-65	List-driven fan-out with a per-unit ledger	partial (narrowed)	Narrowed on re-check: agent-to-agent delegation already ships, bounded by a collaborators allow-list, a depth cap and a sibling fan-out cap, and returns a typed result. What is missing is the list-shaped primitive: let one running agent spawn N bounded sub-runs over a list — 100 sources, 50 documents, 200 items — each with its own fresh context, scheduled concurrency, soft-then-hard timeouts and a spend ceiling, with results returning as structured turns in the parent run and merged deterministically so analysis quality does not decay down the list. Pair it with a shared, queryable ledger recording one row per unit of work, so the parent validates progress against data rather than prose, and a killed parent resumes from the ledger.	A list fan-out tool in packages/agent/src/agents/agent-tool.service.ts beside the existing delegation tool; a run_unit ledger table; extends docs/features/sessions-and-steering.md and docs/features/workers.md.	M — one tool plus one ledger table over an existing bounded-delegation path	A research run over two hundred items is as good on item two hundred as on item one.
G-66	Context spillover and structure-preserving compaction	missing	Bound what a long run costs and how far it can go. Spill large tool results to files above a size threshold and replace them in the transcript with a pointer the agent dereferences on demand; keep tool-call structure intact through compaction rather than flattening it to prose; list the available spill files in the system prompt each turn; and write a compact, re-loadable handoff summary at the end of every run so the next run resumes from it instead of re-reading everything. This directly determines how long an autonomous run can usefully continue.	Extends packages/agent/src/agents/prompt-assembler.service.ts; spill storage through the existing storage plugins; new docs/features/agent-context.md.	M — a prompt-assembly change plus a spill store	Long autonomous runs stay coherent and affordable instead of degrading as the transcript grows.
G-67	Long-session park and resume across process death	partial	Persist a run cursor to durable storage so a killed, restarted or rescheduled worker resumes exactly where it stopped, including mid-turn, and so a session can outlive the job that hosts it. A session is hard-capped at one hour of wall-clock time by its host job today, and park-and-resume for genuinely long-lived sessions is explicitly not shipped, which caps how ambitious a single autonomous run can be. Name the park reasons explicitly so an operator can see why a run is waiting.	A run cursor persisted beside the agent run entity; extends docs/features/agent-terminals.md and docs/features/sessions-and-steering.md.	M — a cursor plus resume semantics on the run path	A multi-hour piece of work survives a restart instead of dying at the one-hour host cap.
G-68	Organization-wide always-on policy prompt	missing	A single plain-language, versioned rulebook set at organization scope and prepended above every agent's own instructions on every run and every generation, with per-Agent overrides and a live token estimate. Keep it stable across turns so it lands on the provider's prompt-cache boundary. The closest things today are per-Agent identity files and per-Work prompt overrides; neither gives one place to say "never do X" and have every agent obey it. The prompt assembler composes eleven named segments with per-segment token caps and has no organization-scope segment.	A new organization setting; composed as the top segment in packages/agent/src/agents/prompt-assembler.service.ts; a per-Agent override field; new docs/features/organization-policy.md.	S — one segment in an existing assembler, plus a setting	An organization writes its rules once and every agent it owns follows them.
G-70	Two-way agent control from more chat platforms	partial	Generalise the pattern the one bidirectional connector proves — mention or slash command, signature-verified and fail-closed, routed into platform chat with a threaded reply — into a reusable bidirectional connector contract, then implement it for Telegram, WhatsApp, Discord and at least one regional platform. Include a pairing handshake where a first inbound message produces a short-lived code the owner approves, an access allow-list, per-conversation session isolation and in-channel session controls. Critically, a human reply in the channel must un-park a run waiting on an escalation, which turns chat from a notification sink into an approval surface. Note one live inaccuracy to fix: a connector describes itself as bidirectional while its inbound half is still a follow-up.	Promote the notification-channel plugins to full connectors with direction: bidirectional and an event-source leg; extends docs/features/{integrations,connectors,notifications,approvals-and-escalations}.md.	M — one contract plus three or four implementations	An operator approves gated work from their phone, in whichever chat app they already use.
G-71	MCP OAuth install, stdio transport, curated catalogue	partial	External MCP servers already register, bind per Agent and surface their tools under the grant matrix, with encrypted auth headers and SSRF-guarded URLs. Three additions close the gap: OAuth-authenticated servers so a user clicks through the provider's consent flow instead of pasting a bearer token; the stdio transport and package-sourced servers so local and installed servers are reachable; and a curated catalogue of pre-wired connections with one-click install, so common integrations are not a manual URL entry every time. Work-scoped bindings, already reserved in the model, complete the scope lattice.	Extends packages/agent/src/mcp/mcp-connections.service.ts and mcp-client.service.ts; a Git-backed catalogue repo like the agents and skills catalogues; updates docs/features/mcp-connections.md.	M — one transport, one auth flow, one catalogue	Connecting a tool becomes a click, not a URL and a pasted token.
G-91	Task collaborator UI — reviewers, approvers, blockers	partial	Reviewers, approvers, blocker dependencies, relations and dual-type assignees already exist in the data model and the REST API, but no screen creates them, so the governance story is API-only in practice and no user can exercise it. Build the screens over the endpoints that already exist: assign a reviewer or approver, declare a blocking dependency, watch a task, and see a task's blockers and dependents. Add the missing watcher endpoint, which is a table with no route today.	A collaborator panel in apps/web/src/components/tasks/; the missing watcher endpoint in apps/api/src/tasks/; updates docs/features/tasks.md.	S — the hard part already shipped; this is one panel and one route	Task governance becomes usable by a person rather than only by an API client.
G-75	Environments — services, pinned runtimes, real consumers	partial	Extend the per-Agent environment recipe from packages and an egress policy to a full execution environment: a database and cache service available to the run, pinned language runtime versions, and a preparation script that runs once before the agent starts. Then make more than one pipeline honour it — today it is advisory metadata to every pipeline but one, which makes the feature effectively undelivered for most users.	Extends docs/features/environments.md and the pipeline plugin contract so every pipeline reads the environment; service definitions provisioned by the job runtime.	M — a contract change plus adoption across the pipelines	The environment an operator configured is the environment the agent actually runs in.
G-81	Business-tool connector breadth	partial	Eleven native connectors is thin against buyers who expect their stack to be reachable. Rather than hand-writing hundreds, use two levers: ship the curated MCP catalogue so any MCP-exposed product becomes bindable in one click, and add the specific first-party connectors the go-to-market pipeline is starved of — an enrichment provider, a second CRM tier, a calendar, and at least one data warehouse so Goals can read a warehouse metric. Use official vendor SDKs, never raw REST.	New connector plugins in packages/plugins/; extends docs/features/connectors.md and docs/features/goals.md; depends on G-71 for the catalogue lever.	M — four first-party connectors plus the catalogue	The go-to-market pipeline can reach the systems a buyer actually runs on.
G-82	First-party trigger sources — email, calendar, reaction	partial	Inbound triggers already exist as a strong object: a signed HTTPS endpoint with a rotatable secret, a replay window, event matchers, a per-event double-fire guard and prompt-injection escaping of the payload. What is missing is turnkey sources on top of it — an inbound email filtered by sender, subject, body or domain; a calendar event from a connected calendar; a chat reaction; and a completion event from a connected meeting or deploy. Each becomes a selectable source in the existing trigger UI rather than a webhook the user has to wire. Agent mailboxes already exist and no trigger rule binds to arrival.	New source kinds in docs/features/inbound-triggers.md (two sources today: a signed webhook and a platform-event matcher); reuses the agent mailboxes and the calendar connector.	S — new source kinds over an existing trigger object	"When I get an email like this, start the work" is a dropdown, not a webhook project.
G-90	Reconcile remaining stale counts and contradictions	partial (narrowed)	An internal accuracy item: several documentation pages disagree with the repository or with each other, and each is a number an external comparison might cite. Narrowed on re-check — two of the originally listed contradictions are already fixed (the comparison page now reads 102 plugins and 11 AI providers, and the API reference no longer claims there are no API keys). Still open: the architecture page's repository tree says 39 plugins while the tree holds 102; the budgets page says "three scopes" and then lists four, omitting the per-Agent budget documented elsewhere; and the Git-provider contradiction, where one page says GitHub is the only implemented provider while the create-a-Work and onboarding pages present GitLab as connectable. Add a CI check that fails when a documented count diverges from the tree.	Doc edits in docs/architecture.md, docs/features/budgets-and-usage.md, docs/features/git-operations.md, docs/features/creating-a-work.md, docs/features/onboarding.md, plus a scripts/ count-consistency check wired into CI.	S — three edits and one guard	Nobody quotes a number from our docs that our own repository contradicts.

P2 — real, but lower urgency or narrow to one segment

Shorter form: one-sentence spec, suggested home, effort. Same rules — paste-safe, no outside product named. Promote a row to P1 by writing it out in the table above rather than by editing this list in place.

• G-27 — In-product domain purchase · missing · M — Search, buy and auto-configure a domain from inside the product, with DNS and TLS handled for the buyer at any registrar, not only where a managed DNS plugin exists. Home: new registrar plugin capability; extends docs/features/custom-domains.md.

• G-28 — Mobile companion · missing · M — A phone surface to read digests, watch runs, approve gated work, answer an escalation and prompt an agent by voice; an installable PWA with push is the pragmatic first increment. Home: a PWA manifest on the dashboard, or a new apps/mobile.

• G-29 — More deploy targets · partial · M — Deployment plugins for a static/edge host, a self-hosted container PaaS and a generic Docker VPS alongside the two that exist, so the deploy story is not two vendors. Home: new plugins in the existing deployment category.

• G-30 — Agent-readable catalog over an open commerce protocol · missing · M — Publish a Work's structured catalog over an open agentic-commerce protocol so third-party shopping and answer agents can discover and transact against it; an integration decision, not a moat to rebuild. Home: a protocol endpoint on the generated site; extends the MCP server scope. Depends on G-10.

• G-33 — Visitor assistant and a per-Work MCP endpoint · missing · M — Ship an embeddable assistant on the generated site backed by that Work's content and knowledge base, and expose the same Work over MCP so a visitor's own agent can query the catalogue without scraping. Home: a widget in the templates; a /_api/mcp route per site.

• G-37 — Ad placements with campaign scheduling · partial · M — Named banner slots sold as campaigns with start and stop dates, rotation, category or geo targeting, impression and click counting, an advertiser report, and an automatic rel="sponsored" on paid outbound links. Home: extends the template's sponsor-ad model.

• G-38 — Voice input and spoken responses · partial · M — Extend push-to-talk dictation into a real voice session — spoken prompts and spoken agent replies — with an on-device path so audio need not leave the machine. Home: a speech capability in the plugin system; extends docs/features/platform-chat.md.

• G-39 — Multi-criteria reviews and owner replies · partial · S — Let visitors rate several axes per listing with per-axis aggregates, let a verified listing owner reply publicly, and let an agent flag suspected review manipulation for moderation. Home: extends the template's comment and rating model. Pairs with G-34.

• G-40 — Bookings and business hours · missing · M — Structured opening hours with timezone handling and a live open/closed badge, plus appointment or reservation requests with slot selection, calendar sync and optional prepayment. Home: a new template block plus a calendar plugin binding.

• G-41 — Redirects manager · missing · S — Manage 301/308 redirect lists per Work, importable from CSV and applied through the deploy plugins, so a site restructure does not lose its links. Home: redirects[] in works.yml; a deploy plugin contract addition.

• G-42 — Accessibility check as a gate kind · missing · S — A bundled accessibility gate — contrast, alt text, heading order, landmarks, keyboard order — that runs on the preview or the deployed site and reports findings on the Task. Home: a new a11y gate check kind. Pairs with G-25.

• G-43 — White-label and reseller mode · missing · L — Branded dashboard, logo and emails per organization, client sub-accounts scoped to a single company, and pass-through billing, so an agency can resell the platform. Home: branding fields on the organization; extends docs/advanced/multi-tenancy.md.

• G-44 — Provider breadth and a generic compatible endpoint · partial · S — Add the three major cloud-vendor inference services and one generic OpenAI-compatible endpoint provider covering every self-hosted and long-tail model server in a single plugin, plus provider auto-detection from a pasted key prefix. Home: new ai-provider plugins.

• G-46 — Events, jobs, classifieds and coupons as content types · missing · L — Per-type schemas, routes and agent skills for dated events with recurrence and calendar export, job listings, short-lived classifieds with auto-expiry, and coupons with a validity window and redemption tracking. Home: new kinds in the works.yml per-kind spec shapes.

• G-47 — Saved-search alerts and web push · missing · S — Let a visitor save a filter and receive an email or web push when new matching content appears, turning scheduled generation into a retention loop. Home: saved_search in the template; reuses the notification channels.

• G-50 — Content-quality gate kinds · missing · M — Gate kinds that check a draft against the Work's style and brand knowledge-base documents, verify factual claims against cited sources, and score readability, so publishing on a cadence never costs editorial voice or accuracy. Home: new check kinds beside build/test/lint/typecheck/custom. Pairs with G-13.

• G-53 — Paid membership tiers and a post paywall · missing · M — Gate reading a post or a page behind a membership tier, with free and members-only content, mid-post paywall breaks, a reader signup portal and a customer portal. Home: extends the template's plan-feature guard to content.

• G-54 — Referral and cross-Work recommendation loops · missing · M — A milestone-based reader referral programme and an opt-in recommendation graph across Works on the platform, so a new Work does not start from zero audience. Home: depends on the G-18 subscriber model.

• G-55 — Audio narration and a podcast feed · missing · S — Text-to-speech narration of generated pages and posts, published as an RSS podcast feed alongside the existing feeds. Home: a speech capability plus a feed route. Shares the capability with G-38.

• G-56 — AI-authorship provenance and disclosure · missing · S — First-class provenance on generated content — which agent wrote it, what reviewed it, which sources it used — rendered as an optional public disclosure block and as author markup. Home: provenance fields on the content record plus a template block.

• G-57 — Product feed and marketplace distribution · missing · M — Generate and maintain a product feed for the major shopping and social channels from a store Work's catalog. Home: a new feed plugin. Depends on G-10.

• G-58 — Compliance posture and a public trust page · missing · L — Pursue a recognised security attestation and publish a trust page covering certifications, retention, sub-processors and model-training stance, so procurement has a document to accept; self-hosting answers data control but not an audit questionnaire. Home: a new security and compliance page in docs/ and on the website.

• G-59 — Workflow durability: retries, compensation, inspection · partial (narrowed) · M — Narrowed on re-check: the saved workflow graph already ships — a workflow entity with draft/active/archived lifecycle, a workflow_run record, a graph executor and an apps/api/src/workflows module. What is missing is the durability layer on top: per-step retries, compensating steps, mid-flight inspection and resume after a restart, plus a screen so a workflow is user-visible rather than API-only. Home: extends the existing workflow entity and docs/features/workers.md.

• G-60 — Bi-temporal knowledge facts · missing · M — Store facts with validity windows so an agent can ask what was true at a past point, with deterministic replayable semantics, rather than only current state and a supersession chain. Home: a facts sub-store beside the knowledge base.

• G-69 — Sandboxed disposable execution backends · partial · M — Run an agent turn inside a throwaway remote sandbox rather than on the platform host, for isolation and burst capacity, selected per Agent or per Task. Home: new sandbox providers in the workspace category.

• G-72 — Each Agent published as its own MCP endpoint · missing · S — Publish every Agent as a callable MCP endpoint exposing that Agent's own tools, resources and instructions, so an external client or another agent can call one specific Agent rather than the whole platform API. Home: a per-agent route in apps/mcp.

• G-73 — Community skills, agents and plugin registry · partial · L — Add third-party publishing, scanning, moderation and install to the catalogues, keeping first-party curation as the default trust tier and marking community content clearly; an open-upload model is where supply-chain incidents originate. Home: extends the Git-backed catalogue repos and docs/features/plugins.md.

• G-74 — Portable organization bundle · partial · M — Export a whole organization — agents, teams, skills, works, tasks, schedules, knowledge — as one bundle with secrets scrubbed and collision handling on import, so a setup can move between instances or be shared as a starting point. Home: extends docs/features/data-management.md.

• G-76 — Third-party agent installation protocol · missing · L — A registration flow that lets an outside vendor's agent be installed into an account, appear in assignment pickers, be delegated Tasks and act as a first-class participant, with revocable per-scope permissions. Home: external-agent registration in apps/api/src/agents/.

• G-77 — Accountable human owner on delegation · missing · S — A Task or Work carries a named human owner that delegating to an agent never transfers; the agent is recorded as a contributor on the run. Cheap, and the single best governance idea on this list. Home: an owner field plus contributor rows on the run.

• G-78 — Hosted runtime for user-authored code · missing · L — Let a user deploy a small function to the platform that syncs data on a schedule, exposes a deterministic tool to agents, or handles an inbound webhook, without publishing a plugin package or standing up infrastructure. Home: a function runtime beside the job runtimes.

• G-79 — Cross-source unified search · partial · M — Extend organization-wide search from a lexical title-and-description index to full document bodies with semantic ranking, and include connector-ingested content, so one query reaches everything the organization knows. Home: extends the org memory index; reuses the vector-store plugins.

• G-80 — Connector historical backfill · missing · M — Crawl existing history when a connector is enabled, so a new workspace is useful on day one instead of after weeks of forward-only ingest. Home: a backfill mode on each event-source plugin.

• G-83 — Live meeting attendance · missing · M — Join a live call as a participant with real-time transcription rather than waiting for a cloud recording, and add a Teams source alongside the two that exist. Home: extends docs/features/meetings.md sources.

• G-84 — Triage of the operator's own mailbox · missing · M — Connect a user's own mail account so agents can label, sort, archive and draft in it, distinct from the mailboxes agents already have of their own. Home: a new mail-account connector.

• G-85 — Natural-language agent builder · partial · S — Describe the job in a sentence and get a drafted Agent back — identity files, capabilities, a proposed heartbeat, a budget and tool grants — ready to review and start, instead of a five-step form. Home: a generation step behind the existing create-agent flow.

• G-86 — Internal dashboard or small internal app as an output · missing · L — Let an agent build a live internal dashboard or small internal tool from connected data as a deliverable, alongside public sites and digests; the missing output size between a one-line alert and a full public site. Home: a new work kind or artifact type.

• G-87 — Computer use beyond headless browsing · partial · L — Extend browser automation toward a supervised session that can use the operator's authenticated logins and drive applications with no API, under per-action approval and a full action log. Home: extends packages/plugins/browser-automation.

• G-88 — Revisioned plans with an explicit approval gate · partial · M — A versioned plan artifact reviewed and approved before execution starts, with revisions tracked, for strategy-heavy work where an Idea is too light and a Task is too late. Home: a new plan entity between Idea and Task.

• G-89 — Prebuilt runnable ops-workflow archetypes · partial · M — Installable, runnable archetypes for the three jobs buyers ask for first — answer repeat questions from a knowledge source, triage and route incoming requests, post a recurring status report — so a new account has working automation in minutes. Home: new entries in the agents and mission-template catalogues.

• G-92 — Dependency-aware batch execution of Tasks · partial · M — Let a group of Tasks declare or infer ordering and auto-dispatch every unblocked Task in parallel as its predecessors go green, instead of a flat top-of-column run. Home: dependency edges on the task entity; extends docs/features/tasks.md. Pairs with G-91.

• G-93 — Dispatch-time contradiction check · partial · S — Before a Task runs, check its description against accepted decision documents and flag a conflict with the specific conflicting record attached — advisory only, never blocking, never fabricating a conflict. Home: reads the decision corpus at dispatch; extends docs/features/memory-decisions.md.

• G-94 — Memory health scoring and a consolidation pull request · partial · M — Surface drift, staleness and contradiction metrics over the knowledge base, and let one click queue a consolidation pass that opens a reviewable pull request which only appends, never deletes a record or rewrites history. Home: extends the consolidation path in docs/features/memory.md.

• G-95 — Free-form agent-written reports · partial · M — Pick a preset or describe what you want, and have an agent read the Work's repository plus its connected sources and write the document, distinct from the fixed-shape scheduled digests that already ship. Home: a report artifact type; extends docs/features/digests.md.

• G-96 — Egress ledger and right-to-be-forgotten · missing · M — An append-only record of what context left the machine on each provider call, plus a purge that deletes an inference and its ledger entries; a strong story for privacy-constrained self-hosters. Home: a ledger beside the usage ledger.

• G-97 — Preference learning from human corrections · missing · M — Diff what the agent proposed against what the human actually shipped, require a verbatim evidence span for any inferred preference, and harden it only once it recurs across separate sessions, so agents stop repeating corrected mistakes. Home: correction capture on merge, writing into the review queue.

• G-98 — Zero-setup first output and one-command local bootstrap · partial · M — Produce a few real artifacts before the provider, storage, database and deployment wizard so a prospect sees output before committing configuration; and ship a single command that scaffolds and starts the whole stack locally with no account. Home: extends docs/features/onboarding.md and the desktop installer.

• G-99 — Finish or retire the Knowledge Base create-document control · partial · S — KbAddDocButton.tsx and KbAddDocModal.tsx are unreferenced dead code, and their dashboard.workDetail.kb.addDoc strings still ship, so the control reads as real in the source while a user cannot reach it. Four docs pages told readers to click it before that was corrected; the underlying split remains. Either wire the button into the workbench (the API and MCP paths it would call already exist) or delete the components and their strings — leaving a third state is what produced the wrong documentation. Home: apps/web/src/components/works/detail/kb/; touches docs/features/knowledge-base.md.

Checked and removed

Every row above was re-checked against this repository before it was listed. These did not survive the check as gaps. Their ids are retired, not reused.

ID

Why it is not a gap

G-23

Per-account outbound signed webhooks already ship. packages/agent/src/entities/webhook-subscription.entity.ts (endpoint, encrypted HMAC signing secret, paused/failed status, consecutive-failure counter) and webhook-delivery.entity.ts, served by apps/api/src/webhooks/ — subscriptions controller, secret service, delivery service and event dispatcher — and documented in docs/features/webhooks.md with signature verification, retries with backoff and a deliveries log. Two narrower follow-ups remain and are worth their own rows if anyone asks for them: the subscribable event set is Work created / generated / deployed rather than every entity event, and the surface is API-only with no dashboard screen. Neither is the missing capability the review described.

Four further rows were narrowed rather than removed, because a re-check found part of them already shipped. Each carries a "narrowed on re-check" note in its spec, and the spec text describes only the half that is genuinely missing:

• G-45 — the node worker host, its task executors, the fleet job runtime, per-Agent node affinity, per-scope execution preferences and the local model-CLI launcher all ship; only the billing posture and the packaging remain.
• G-65 — bounded agent-to-agent delegation with depth and sibling fan-out caps ships; the list-shaped fan-out and its per-unit ledger do not.
• G-25 — the browser-automation plugin and a fleet browser-check executor ship; the gate kind that consumes them does not.
• G-90 — two of the six documentation contradictions are already fixed; three remain, and only those are listed.
• G-59 (P2) — the saved workflow graph, its run record, its executor and its API module ship; the durability layer and a user-visible screen do not.

One naming collision was found and is called out in G-32: the capability name the review suggested, data-sync, is already taken by the shipped data-repository instant-sync module in apps/api/src/data-sync/. Pick a different name.

Deliberately not building

Recorded so they stop resurfacing on every pass. Each is a decision, not an oversight.

Not building	Reason
Native mobile app output — generating an iOS or Android app from a Work	Outside the content-and-code-for-business-websites wedge. An operator companion app (G-28) is a different, defensible thing and stays on the list.
Reciprocal backlink exchange and automated link networks	The capability most often reported as broken by the people who use it, and it carries real search-penalty risk. If off-page is addressed at all, prefer outreach as an agent Task with human approval.
Copying third-party reviews into listings	Generally outside the source platform's terms. Import ratings only where the source explicitly permits it.
Building checkout, tax, fraud or PCI scope ourselves	Adopt a commerce backend through a connector (G-10f). The differentiator is catalog research and content, not payment rails.
Deep B2B commerce constructs — quotes, company accounts, cascading price lists	Only reachable through a connected commerce backend, and only if the mid-market segment is pursued deliberately.
Telephony and voice agents answering calls	Far from the wedge; revisit only if the Company Builder work makes it load-bearing.
Video hosting, livestreaming, a recording studio	Media hosting is a different business. Audio narration (G-55) is the bounded, defensible slice.
A single hosted-only posture	Explicitly the opposite of the product. Every gap above must be implementable by a self-hoster or it is scoped wrong.

Keeping this file honest

• Re-check before you quote a row. A row states the repository as it was when the row was written. Confirm it against the tree before starting work, and if it already shipped, move it to Checked and removed with the paths that prove it rather than deleting it.
• Never add attribution. No product name, no "who has it", no convergence count. If a row cannot be justified in Ever Works' own terms, it is not ready to be listed.
• A row is not a promise. Publishing a roadmap entry on the website is a separate decision, taken deliberately, by someone who can commit to it.
• Nothing here proposes deleting anything. Every entry is additive. Where a document and the code disagree, the entry names the reconciliation as its own work item rather than resolving it silently.