{ "counts": { "not supported": 87, "partially supported": 39, "technically supported": 0, "total": 149, "validated end to end": 23 }, "generatedFrom": "docs/benchmarks/CRM_JTBD_MATRIX.md", "jobs": [ { "docs": [ "docs/ADMIN.md", "docs/ADMIN_SMOKE.md" ], "id": "JTBD-01", "section": "CRM JTBD validation matrix", "status": "validated end to end", "summary": "create the object type, then list/create/view/edit its records through the Admin.", "tests": [ "tests/admin-core.test.js", "tests/admin-modules.test.js", "tests/generated-api-e2e.test.js", "tests/module-factory-e2e.test.js" ], "title": "Manage a custom CRM business object end to end", "url": "https://accordo.dev/jobs/jtbd-01.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [ "docs/MODULE_FACTORY.md" ], "id": "JTBD-01b", "section": "CRM JTBD validation matrix", "status": "validated end to end", "summary": "(Milestone 5), for generated-to-generated many-to-one references only.", "tests": [ "tests/admin-modules.test.js", "tests/module-factory.test.js", "tests/reference-fields-e2e.test.js", "tests/reference-resolver.test.js" ], "title": "Associate a generated CRM record with another generated CRM record", "url": "https://accordo.dev/jobs/jtbd-01b.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-02", "section": "CRM JTBD validation matrix", "status": "validated end to end", "summary": "(Milestone 0), for the built-in renewal object.", "tests": [ "tests/api.test.js", "tests/workflow.test.js" ], "title": "Request commercial approval on a deal", "url": "https://accordo.dev/jobs/jtbd-02.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [ "docs/ADMIN_SMOKE.md" ], "id": "JTBD-03", "section": "CRM JTBD validation matrix", "status": "validated end to end", "summary": "(Milestone 8) for code-first pipelines on the built-in Opportunity module. The legacy fixed stage enum remains what the renewal-approval policy runs on (unchanged evidence: tests/workflow.test.js).", "tests": [ "tests/admin-pipeline.test.js", "tests/opportunity-pipeline-e2e.test.js", "tests/pipeline-contract.test.js", "tests/workflow.test.js" ], "title": "Manage a deal through pipeline stages", "url": "https://accordo.dev/jobs/jtbd-03.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [ "docs/ADMIN_SMOKE.md" ], "id": "JTBD-04", "section": "CRM JTBD validation matrix", "status": "validated end to end", "summary": "(Milestone 6), for the starter's Lead model.", "tests": [ "tests/lead-qualification-e2e.test.js" ], "title": "Capture a lead", "url": "https://accordo.dev/jobs/jtbd-04.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [ "docs/ADMIN_SMOKE.md" ], "id": "JTBD-05", "section": "CRM JTBD validation matrix", "status": "validated end to end", "summary": "(Milestone 6), for the starter's qualify/disqualify actions.", "tests": [ "tests/action-contract.test.js", "tests/action-runtime-semantics.test.js", "tests/admin-actions.test.js", "tests/lead-qualification-e2e.test.js" ], "title": "Qualify (or disqualify) a lead", "url": "https://accordo.dev/jobs/jtbd-05.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [ "docs/ADMIN_SMOKE.md" ], "id": "JTBD-05b", "section": "CRM JTBD validation matrix", "status": "validated end to end", "summary": "(Milestone 7), for the starter's convert action.", "tests": [ "tests/action-contract.test.js", "tests/admin-actions.test.js", "tests/lead-conversion-e2e.test.js" ], "title": "Convert a qualified lead into Company, Contact and Opportunity", "url": "https://accordo.dev/jobs/jtbd-05b.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-06", "section": "CRM JTBD validation matrix", "status": "partially supported", "summary": "generated CRUD is validated (JTBD-01), but the factory does not yet generate workflows/approvals for custom objects.", "tests": [], "title": "Manage a custom object with an approval rule", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [ "docs/WORK_TASKS.md" ], "id": "JTBD-07", "section": "CRM JTBD validation matrix", "status": "partially supported", "summary": "Work supplies reusable Tasks and Activity. Explicitly composed self-host timer consumers can open a Work ask through an application-started worker; dueAt alone starts nothing. No recurrence, notification delivery, assignment automation or managed worker service is included.", "tests": [ "tests/lead-qualification-e2e.test.js", "tests/work-operations-e2e.test.js", "tests/work-operations-evidence.test.js", "tests/work-package-absence.test.js", "tests/work-provenance-and-actor.test.js", "tests/work-source-key-stability.test.js" ], "title": "Schedule next actions / follow-ups", "url": "https://accordo.dev/jobs/jtbd-07.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-08", "section": "CRM JTBD validation matrix", "status": "validated end to end", "summary": "superseded by JTBD-DS-01, which is the current row for this job and carries its evidence. This row is kept because \"hand off a won deal\" is the phrasing a reader or an agent searches for; it said \"there is no handover process, no delivery project and no acceptance\" long after M13, M14a and M14b2 shipped all three, so the same file answered the same question two opposite ways. Activating a contract (M12) records explicit pending obligations from the signed order; M13 turns them into a Delivery Project with work packages and milestones, M14a runs it, M14b2 records deliverables and acceptance.", "tests": [ "tests/contracts-activation-e2e.test.js", "tests/delivery-execution-e2e.test.js", "tests/delivery-handover-e2e.test.js" ], "title": "Hand off a won deal", "url": "https://accordo.dev/jobs/jtbd-08.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-09", "section": "CRM JTBD validation matrix", "status": "not supported", "summary": "no checklist/onboarding primitives.", "tests": [], "title": "Onboard a customer", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/CONTRACT_ACTIVATION.md", "docs/RENEWAL_AMENDMENT.md" ], "id": "JTBD-10", "section": "CRM JTBD validation matrix", "status": "partially supported", "summary": "contract activation, human renewal intent and governed successor execution exist, retaining signed-term provenance and immutable lineage. Timer consumers can open lifecycle-review asks when an application explicitly starts its worker. They do not automatically renew, cancel, bill or notify; historical contracts are not edited.", "tests": [ "tests/contracts-activation-e2e.test.js", "tests/lifecycle-amendment-execution-e2e.test.js", "tests/workflow.test.js" ], "title": "Manage contracts and renewals", "url": "https://accordo.dev/jobs/jtbd-10.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-11", "section": "CRM JTBD validation matrix", "status": "not supported", "summary": "no health-scoring/activity primitives.", "tests": [], "title": "Identify churn risk", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-12", "section": "CRM JTBD validation matrix", "status": "not supported", "summary": "no usage/entitlement primitives.", "tests": [], "title": "Identify upsell", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-13", "section": "CRM JTBD validation matrix", "status": "partially supported", "summary": "data is queryable via API/SDK and the dashboard shows counts; no reporting/aggregation surface for generated modules.", "tests": [], "title": "Report pipeline", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-14", "section": "CRM JTBD validation matrix", "status": "not supported", "summary": "only an in-memory notification provider contract exists; no email/calendar/marketing adapters.", "tests": [], "title": "Integrate email / calendar / marketing", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-15", "section": "CRM JTBD validation matrix", "status": "partially supported", "summary": "Production Spine v1 (ADR-038) enforces the permission half: organizations, memberships, eleven bounded permissions in five role bundles, server-authoritative authorization on every route, one tenant per application instance, and a fail-closed actor boundary. The identity underneath it is not validated: the framework authenticates nobody and ships no verifier, so *which* person holds a membership is only as trustworthy as the deployment adapter, and in local-development mode it is an assertion. This is not shared-database multi-tenancy, and remote exposure still requires a verifier the framework does not provide.", "tests": [ "tests/actor-fails-closed.test.js", "tests/production-spine.test.js", "tests/spine-route-authorization.test.js", "tests/spine-tenancy-truth.test.js" ], "title": "Enforce team / tenant permissions", "url": "https://accordo.dev/jobs/jtbd-15.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-AN-01", "section": "Analytics (target: M16)", "status": "not supported", "summary": "no semantic model or metric-definition primitives", "tests": [], "title": "Define a trusted, explainable metric", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-AN-02", "section": "Analytics (target: M16)", "status": "not supported", "summary": "no report/query-compilation primitives", "tests": [], "title": "Create a report from approved metrics/dimensions", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-AN-03", "section": "Analytics (target: M16)", "status": "not supported", "summary": "requires RBAC at the query boundary — gated by the Production Spine", "tests": [], "title": "Create a role-aware dashboard", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-AN-04", "section": "Analytics (target: M16)", "status": "not supported", "summary": "no dashboard-version primitives", "tests": [], "title": "Version and roll back a dashboard", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-AN-05", "section": "Analytics (target: M16)", "status": "not supported", "summary": "no metric test harness", "tests": [], "title": "Validate metric correctness against fixtures", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-AX-01", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "validated end to end", "summary": "accordo app inspect [--json] (AX1) answers it in one deterministic document: the installed package graph with its five distinct version axes, the resolved capability graph including unresolved edges, records with their revisions, actions with declared transition metadata, policies and provider definitions. An invalid composition still produces a complete report with deterministic problems[], and limitations[] names every gap by code — tests/app-inspect.test.js. Source-only: no database is opened, no provider is contacted, and JTBD/quality evidence is referenced by path, never parsed", "tests": [ "tests/app-inspect.test.js" ], "title": "Discover installed packages, capabilities and policies", "url": "https://accordo.dev/jobs/jtbd-ax-01.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-AX-02", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "validated end to end", "summary": "the package contract: a customer-authored package attaches, works and detaches with every kernel file fingerprinted unchanged (JTBD-PK-01/PK-02). A record that must gain a field or a status evolves by revision (ADR-019)", "tests": [], "title": "Extend the CRM for a goal without patching the kernel", "url": "https://accordo.dev/jobs/jtbd-ax-02.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-AX-03", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "partially supported", "summary": "AX2: solutionPlanContract: 1 with a revision and a canonical fingerprint, six decision types mapped to the repository's own hierarchy, six evidence categories with resolving citations, a closed approval vocabulary, and accordo solution inspect|validate|check — check binds the plan to this project's app inspect report and reports PLAN_STALE when the composition has moved. A plan cannot carry a command, rung 5 cannot be a step, rung 3 and above must evidence the rungs they inspected, and citations follow a DAG over evidence categories so a conclusion cannot be cited as a premise — tests/solution-plan.test.js. Partial, not validated: nothing writes the plan (there is no planner) and nothing executes it (there is no runtime); the contract makes a hand-written plan checkable, which is a different job from producing one", "tests": [ "tests/solution-plan.test.js" ], "title": "Turn a business objective into a reviewable solution plan", "url": "https://accordo.dev/jobs/jtbd-ax-03.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-AX-04", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "partially supported", "summary": "true for modules, actions, policies, packages and Admin views that exist today; the analytics and campaign parts of a typical funnel goal cannot be built at all", "tests": [], "title": "Build the solution as checked-in, customer-owned source", "url": "https://accordo.dev/jobs/jtbd-ax-04.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-AX-05", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "partially supported", "summary": "Quality Gates, crm package validate, the test suites and the clean-clone run are real and enforced, and DX10 now closes the last hop from a plan to its proof: accordo solution verify --evidence --json reports, per requirement, whether it is proven, partial, blocked, unevidenced, stale or unverified, from authorities that ran in the same invocation. A requirement id is derived from the plan, the evidence document has no status field, and file exists can never satisfy a behavioural requirement — tests/implementation-evidence.test.js, tests/solution-verify.test.js. Still partial, and deliberately so: it grades the acceptance a plan *wrote down* and cannot catch one it omitted, manual requirements stay unverified, no checked-in plan verifies today, and there is still no automated goal-to-acceptance runner (AX3)", "tests": [ "tests/implementation-evidence.test.js", "tests/solution-verify.test.js" ], "title": "Verify the solution against defined acceptance", "url": "https://accordo.dev/jobs/jtbd-ax-05.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-AX-06", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "partially supported", "summary": "the JTBD matrix and package metadata make the honest answer *available*, and two commands now make part of it machine-checked rather than optional: the service scenario publishes each unavailable capability as a stated false it earned by attempting the operation, and accordo solution verify refuses to let an agent declare a requirement met — the evidence document has no status field, a downgrade needs a reason, and a manual requirement can never read as proof. Still partial: nothing enforces that an agent writes an evidence document at all, which is why the Skill states it as a rule", "tests": [], "title": "Report unavailable capabilities honestly", "url": "https://accordo.dev/jobs/jtbd-ax-06.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-AX-07", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "not supported", "summary": "needs Analytics Studio and a funnel primitive", "tests": [], "title": "Analyse a funnel and identify a drop from a goal", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-AX-08", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "not supported", "summary": "MK1 proposal candidate has executable evidence in tests/marketing-e2e.test.js; row promotion awaits milestone review", "tests": [ "tests/marketing-e2e.test.js" ], "title": "Propose an optimization campaign from an insight", "url": "https://accordo.dev/jobs/jtbd-ax-08.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-AX-09", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "not supported", "summary": "AX4; hard-gated by the Production Spine and Cloud", "tests": [], "title": "Deploy, observe and fix a solution in production", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-AX-10", "section": "Agent experience (AX0–AX5, cross-cutting)", "status": "not supported", "summary": "AX5; needs Marketing, Analytics, Data Governance and Durable Automation", "tests": [], "title": "Close the loop: measure, learn, propose the next version", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-CM-01", "section": "Communications (no milestone assigned)", "status": "not supported", "summary": "no email provider; needs the Integration Runtime", "tests": [], "title": "Sync email with CRM records", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-CM-02", "section": "Communications (no milestone assigned)", "status": "not supported", "summary": "no calendar provider", "tests": [], "title": "Sync calendar events", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-CM-03", "section": "Communications (no milestone assigned)", "status": "not supported", "summary": "Work v1 adds a free-text note on a subject timeline, and that is all: there is no meeting, call, participant, duration, direction or outcome model, no calendar and no telephony. A note is not a logged call", "tests": [], "title": "Log meetings and calls", "url": "https://accordo.dev/jobs/jtbd-cm-03.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-CM-04", "section": "Communications (no milestone assigned)", "status": "partially supported", "summary": "Work provides one reusable Task and Activity model. Self-host timer consumers can open scheduled Work asks through an explicitly started worker; dueAt alone starts nothing. Still partial: no recurrence, notification delivery, automatic assignment or managed worker service. See tests/work-operations-e2e.test.js, tests/work-operations-evidence.test.js, tests/work-provenance-and-actor.test.js, tests/work-source-key-stability.test.js and tests/spine-v3c-timer-consumers-postgresql.test.js.", "tests": [ "tests/spine-v3c-timer-consumers-postgresql.test.js", "tests/work-operations-e2e.test.js", "tests/work-operations-evidence.test.js", "tests/work-provenance-and-actor.test.js", "tests/work-source-key-stability.test.js" ], "title": "Schedule and track a follow-up", "url": "https://accordo.dev/jobs/jtbd-cm-04.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [ "docs/strategy/DATA_GOVERNANCE.md" ], "id": "JTBD-CM-05", "section": "Communications (no milestone assigned)", "status": "not supported", "summary": "no preference or suppression model (DATA_GOVERNANCE.md)", "tests": [], "title": "Honor unsubscribe and communication preferences", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-CO-01", "section": "Commercial Operations / CPQ (Milestones 10-11 implemented for the local slice, ADR-016 and ADR-017)", "status": "validated end to end", "summary": "narrow wording: Opportunity → one price book → composite Offers (rate plans with several price components) → controlled server-priced lines mixing one-time and recurring charges with flat / per-unit / volume / graduated models and deterministic tier breakdowns → grouped one-time + per-period totals (never a single grand total) → immutable Quote Version snapshotting component definitions, tier schedules, breakdowns and provenance. NOT included: metered usage, overage, taxes, FX, proration, ramps, minimum commitments, attribute-based pricing, ARR/MRR/TCV", "tests": [], "title": "Create a Quote from a Price Book", "url": "https://accordo.dev/jobs/jtbd-co-01.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-CO-02", "section": "Commercial Operations / CPQ (Milestones 10-11 implemented for the local slice, ADR-016 and ADR-017)", "status": "partially supported", "summary": "validated only for a deterministic fixture catalog provider: immutable product versions and whole-offer revisions (components + tiers), idempotent re-sync, preserved provider provenance (sourcePricingModel, external ids), unsupported models refused rather than flattened, trace. The normalized model can represent Stripe one_time/recurring + volume/graduated tiers and Zuora one-time/recurring + Volume/Tiered pricing, but real Stripe/Zuora/ERP adapters are not supported (no credentials, no adapter ships) and full Stripe Billing / Zuora support is NOT claimed", "tests": [], "title": "Synchronize an external catalog (Stripe/Zuora/ERP/custom)", "url": "https://accordo.dev/jobs/jtbd-co-02.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-CO-03", "section": "Commercial Operations / CPQ (Milestones 10-11 implemented for the local slice, ADR-016 and ADR-017)", "status": "validated end to end", "summary": "basis-point line discounts applied uniformly per component after tier calculation, evaluated by a versioned, fingerprinted discount policy over the grouped totals and component mix, with an explainable bounded decision recorded on the Quote Version", "tests": [], "title": "Request a discount under a deterministic policy", "url": "https://accordo.dev/jobs/jtbd-co-03.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-CO-04", "section": "Commercial Operations / CPQ (Milestones 10-11 implemented for the local slice, ADR-016 and ADR-017)", "status": "partially supported", "summary": "the human-actor boundary is validated (agent actors refused 403; one atomic decision per version; concurrent decisions resolve to one winner) — but requiredApprovalKey is still a label: secure Sales-Manager/Finance role enforcement is not validated, because ADR-038 deliberately left approval keys descriptive rather than promote them into enforced permissions, which would change the meaning of records already written (JTBD-15)", "tests": [], "title": "Obtain required commercial approval on a discount", "url": "https://accordo.dev/jobs/jtbd-co-04.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-CO-05", "section": "Commercial Operations / CPQ (Milestones 10-11 implemented for the local slice, ADR-016 and ADR-017)", "status": "partially supported", "summary": "validated only for the deterministic fixture signature provider: human-actor send boundary (agents refused 403), exactly one envelope per quote version with a deterministic idempotency key, the provider call outside every transaction, a monotonic envelope/signer state machine, and a recoverable failed state with explicit reconciliation. No real DocuSign / Adobe Sign / Dropbox Sign integration exists or is claimed, and no credential ships", "tests": [], "title": "Create a signature envelope with a provider", "url": "https://accordo.dev/jobs/jtbd-co-05.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-CO-06", "section": "Commercial Operations / CPQ (Milestones 10-11 implemented for the local slice, ADR-016 and ADR-017)", "status": "partially supported", "summary": "provider events are verified as the raw signed bytes before any state changes (constant-time HMAC + replay window in the fixture), replay is idempotent by DB-unique provider event id, out-of-order and post-terminal events are recorded and ignored, unknown envelopes are quarantined, and completion produces signed-artifact evidence (hashes, provider reference, signer evidence). Replay scope is provider + event id + payload fingerprint, a reused id with different bytes is refused, and a delivery whose processing failed is resumed rather than stranded. The fixture verification key is test-only: production webhook security, secret management and legally qualified signature assurance are NOT supported, artifactHash is provider-reported, and no artifact byte is downloaded, hashed or cryptographically verified", "tests": [], "title": "Verify signing via verified provider events", "url": "https://accordo.dev/jobs/jtbd-co-06.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-CO-07", "section": "Commercial Operations / CPQ (Milestones 10-11 implemented for the local slice, ADR-016 and ADR-017)", "status": "validated end to end", "summary": "narrow wording: a verified completed signature creates, in one transaction, exactly one immutable Order (DB-unique per quote version) with lines, components, complete tier schedules, band breakdowns and grouped totals copied from the approved Quote Version snapshot, never re-read from the live catalog; duplicate, concurrent and reconciled completions still produce one Order; a real killed process mid-operation recovers by reconciliation with no second envelope; completion fault injection at artifact, order, line, component and total rolls back whole and retries to exactly one complete Order; a later catalog change leaves it byte-identical, and the Order renders its customer, offer, quantities, tier bands, recurrence and grouped totals from order rows alone; a decline or failure creates none. NOT included: fulfillment, billing, invoicing, payment, tax, FX, revenue recognition, amendments, cancellation, renewals", "tests": [], "title": "Create an immutable signed Order snapshot", "url": "https://accordo.dev/jobs/jtbd-co-07.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-CS-01", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "partially supported", "summary": "order.activate-contract (human actor only) creates one contract, its immutable version and one line per order component, atomically and idempotently, with every amount copied from the signed Order. If the quote carries a term, submission freezes it before signature; the canonical document hash covers its dates, auto-renew and notice fields, verified completion copies it to the Order, and activation preserves it as signed-order-terms, refusing manual overrides. Still partial: termless Orders use explicitly reasoned post-signature-operational-activation metadata, not signed terms, and no signed term is backfilled. Signature providers remain offline fixtures, so this does not validate a real external signing deployment. Evidence: tests/signed-terms-e2e.test.js, tests/signed-terms-integrity.test.js, tests/contracts-activation-e2e.test.js, tests/contracts-review.test.js, starter install.mjs", "tests": [ "tests/contracts-activation-e2e.test.js", "tests/contracts-review.test.js", "tests/signed-terms-e2e.test.js", "tests/signed-terms-integrity.test.js" ], "title": "Activate a commercial contract from a signed Order", "url": "https://accordo.dev/jobs/jtbd-cs-01.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-CS-02", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "partially supported", "summary": "one subscription per contract, with a line for every component whose commercial axis is subscription — including recurring components that also carry a service or delivery obligation, so no recurring commitment is lost. Its term inherits the signed Order snapshot when present, or explicitly reasoned operational metadata for a termless Order; the provenance remains visible. Still partial: activation creates commercial records, not billing, proration or cancellation. A future-dated subscription is scheduled; self-host timers can request lifecycle review but do not automatically activate or renew it. Governed amendment execution creates a separate successor agreement without modifying the existing subscription. Evidence: tests/signed-terms-e2e.test.js, tests/contracts-activation-e2e.test.js, tests/lifecycle-amendment-execution-e2e.test.js", "tests": [ "tests/contracts-activation-e2e.test.js", "tests/lifecycle-amendment-execution-e2e.test.js", "tests/signed-terms-e2e.test.js" ], "title": "Activate a subscription with lines and an initial term", "url": "https://accordo.dev/jobs/jtbd-cs-02.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-CS-03", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "not supported", "summary": "still no in-place amendment primitive, and M16b deliberately does not add one: a quantity change produces a successor agreement from its own signed Order, and the live subscription it succeeds is never modified. Reading this row as satisfied would mean claiming that seats moved on the subscription somebody is already on, which is exactly what M16b refuses to do", "tests": [], "title": "Amend seats or quantity on a live subscription", "url": "https://accordo.dev/jobs/jtbd-cs-03.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/RENEWAL_AMENDMENT.md" ], "id": "JTBD-CS-04", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "partially supported", "summary": "M16b executes a governed successor agreement from a signed Order and records the change with a classification derived from the immutable line delta — renewal, expansion, contraction, mixed, or commercial_change when a narrower label cannot be derived — never a client-supplied label. The exact per-line before/after travels with it, grouped by currency and full recurrence. Partial, and narrowly so: quantity direction is derivable only for components that carry a quantity, so a flat-fee line whose amount moved is honestly commercial_change rather than an expansion; a price uplift with no quantity movement is deliberately commercial_change too; nothing is billed, scheduled or notified, and no MRR/ARR/TCV is computed. Evidence: tests/lifecycle-amendment-execution-e2e.test.js, tests/lifecycle-amendment-execution.test.js, tests/admin-lifecycle.test.js, docs/RENEWAL_AMENDMENT.md", "tests": [ "tests/admin-lifecycle.test.js", "tests/lifecycle-amendment-execution-e2e.test.js", "tests/lifecycle-amendment-execution.test.js" ], "title": "Record an expansion or contraction, classified at the time of change", "url": "https://accordo.dev/jobs/jtbd-cs-04.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-CS-05", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "not supported", "summary": "deliberately not derived — M12 now provides a term and an active subscription, but normalizing unlike periods into one figure is a stated business policy that does not exist here; the Admin and the schema say so rather than implying a number", "tests": [], "title": "Calculate MRR, ARR and TCV from real contract data", "url": "https://accordo.dev/jobs/jtbd-cs-05.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/strategy/JOBS_AND_OUTBOX.md" ], "id": "JTBD-CS-06", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "not supported", "summary": "self-host timer consumers can open a lifecycle review ask when an application explicitly starts its worker, but full renewal scheduling and execution are not established by that primitive; automatic renewal and delivered notices remain absent (JOBS_AND_OUTBOX.md)", "tests": [], "title": "Schedule a renewal ahead of term end", "url": "https://accordo.dev/jobs/jtbd-cs-06.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-CS-07", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "not supported", "summary": "needs CS-06", "tests": [], "title": "Create a renewal opportunity from an expiring subscription", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-CS-08", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "not supported", "summary": "unchanged by M16b. The versioned-policy mechanism exists (ADR-015/016/018) and M16b runs the *activation* policy over the successor's components, but it computes no price and applies no uplift: every amount is copied from the signed Order, the live catalog is never read, and a renewal whose amounts moved without a quantity moving is classified commercial_change rather than priced. Uplift needs pricing, which is Commercial's job on the quote that precedes the signature", "tests": [], "title": "Apply a versioned price-uplift policy at renewal", "url": "https://accordo.dev/jobs/jtbd-cs-08.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-CS-09", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "partially supported", "summary": "the non-renew half only, as recorded intent. M16a's record-renewal-decision stores an immutable not_renewing decision with a required human reason, its actor, the term boundary it was taken against and that term's declared provenance. It ends no contract, cancels no subscription, stops no service and recognizes no churn — there are still no cancellation primitives, and the cancel half of this row is not supported. Evidence: tests/lifecycle-renewal-operations-e2e.test.js, tests/lifecycle-renewal-operations.test.js", "tests": [ "tests/lifecycle-renewal-operations-e2e.test.js", "tests/lifecycle-renewal-operations.test.js" ], "title": "Cancel or non-renew with an audited reason", "url": "https://accordo.dev/jobs/jtbd-cs-09.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [ "docs/RENEWAL_AMENDMENT.md" ], "id": "JTBD-CS-10", "section": "Contract & Subscription (Milestone 12 implemented for the local slice — ADR-018 addendum, docs/CONTRACT_ACTIVATION.md)", "status": "partially supported", "summary": "M16b records an immutable contract-succession row per amendment: source and successor contract, version, subscription and Order, the derived classification with its basis, the exact line delta, both terms with their provenance, the term continuity, the signed document hash, the deciding policy version and fingerprint, and who executed it when. Lineage is 1:1:1 and DB-enforced, so the chain is unambiguous. Partial: it is a *successor chain*, not a field-level amendment log — there is no in-place amendment to log — the chain is linear (one successor per agreement), and it starts at M16b: agreements succeeded before it exist have no lineage row and none is backfilled. Evidence: tests/lifecycle-amendment-execution-e2e.test.js, tests/lifecycle-amendment-execution.test.js, tests/admin-lifecycle.test.js, docs/RENEWAL_AMENDMENT.md", "tests": [ "tests/admin-lifecycle.test.js", "tests/lifecycle-amendment-execution-e2e.test.js", "tests/lifecycle-amendment-execution.test.js" ], "title": "Read a complete amendment history", "url": "https://accordo.dev/jobs/jtbd-cs-10.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DC-01", "section": "Design-to-CRM (design only — DESIGN_TO_CRM.md)", "status": "not supported", "summary": "one stylesheet, no token layer", "tests": [], "title": "Apply a brand's colors and typography", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DC-02", "section": "Design-to-CRM (design only — DESIGN_TO_CRM.md)", "status": "not supported", "summary": "navigation is derived from module metadata", "tests": [], "title": "Choose and group Admin navigation", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DC-03", "section": "Design-to-CRM (design only — DESIGN_TO_CRM.md)", "status": "not supported", "summary": "layout is generated from field order in the manifest", "tests": [], "title": "Control field order, sections and responsive layout", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DC-04", "section": "Design-to-CRM (design only — DESIGN_TO_CRM.md)", "status": "partially supported", "summary": "the ADR-009 override seam exists and carries the pipeline board and the quote/signature view — but it is an internal seam with no declared contract, registry or plugin path", "tests": [], "title": "Replace a component without forking the Admin", "url": "https://accordo.dev/jobs/jtbd-dc-04.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DC-05", "section": "Design-to-CRM (design only — DESIGN_TO_CRM.md)", "status": "not supported", "summary": "pixel-perfect generation is explicitly not claimed", "tests": [], "title": "Generate a CRM UI from a Figma file or screenshot", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DC-06", "section": "Design-to-CRM (design only — DESIGN_TO_CRM.md)", "status": "not supported", "summary": "no visual regression; browser tests are not in CI", "tests": [], "title": "Prove the UI still matches its design after a change", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DC-07", "section": "Design-to-CRM (design only — DESIGN_TO_CRM.md)", "status": "not supported", "summary": "no automated checks", "tests": [], "title": "Meet a stated accessibility bar", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DG-01", "section": "Data governance (no milestone assigned — DATA_GOVERNANCE.md)", "status": "not supported", "summary": "no consent primitive", "tests": [], "title": "Record consent and lawful basis", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DG-02", "section": "Data governance (no milestone assigned — DATA_GOVERNANCE.md)", "status": "not supported", "summary": "no outbound paths and no suppression list", "tests": [], "title": "Honor an opt-out across outbound paths", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DG-03", "section": "Data governance (no milestone assigned — DATA_GOVERNANCE.md)", "status": "not supported", "summary": "no subject-access path", "tests": [], "title": "Export everything held about a subject", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DG-04", "section": "Data governance (no milestone assigned — DATA_GOVERNANCE.md)", "status": "not supported", "summary": "the hardest design in the track: commercial evidence is deliberately immutable. Customer Data Foundation v1 does not move this row and does not claim to: it anonymizes and deletes nothing, its canonical link deletes nothing, and governing a data-quality finding records a decision while keeping the finding and its evidence. The only related fact it contributes is a narrow negative one — no raw provider payload is retained from an import — which is a smaller claim than this row asks for and is not a step toward it", "tests": [], "title": "Anonymize or delete a subject while preserving immutable evidence", "url": "https://accordo.dev/jobs/jtbd-dg-04.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DG-05", "section": "Data governance (no milestone assigned — DATA_GOVERNANCE.md)", "status": "not supported", "summary": "retention policy and evidence-producing retention execution are not implemented; generic durable jobs and scheduled asks do not supply them", "tests": [], "title": "Apply a retention policy and evidence that it ran", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DG-06", "section": "Data governance (no milestone assigned — DATA_GOVERNANCE.md)", "status": "not supported", "summary": "M9 records inbound provenance only", "tests": [], "title": "Inspect what was shared with which provider", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DG-07", "section": "Data governance (no milestone assigned — DATA_GOVERNANCE.md)", "status": "not supported", "summary": "needs RBAC", "tests": [], "title": "Restrict sensitive fields by role", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DG-08", "section": "Data governance (no milestone assigned — DATA_GOVERNANCE.md)", "status": "not supported", "summary": "needs DG-04", "tests": [], "title": "Prove a deletion request completed", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DO-01", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "partially supported", "summary": "Customer Data Foundation v1 adds a bounded import under a fingerprinted mapping (customer-rows@1): a preview that provably writes nothing, a per-row receipt carrying an outcome and a reason code, counts that always reconcile (accepted + rejected + skipped == rows), an all-or-nothing or partial acceptance mode, and an idempotency key derived from the source system, the mapping fingerprint and the sorted row digests — never a clock or a random value, so the same import retried is the same run. examples/scenarios/customer-identity-governance.scenario.json, tests/customer-data-foundation.test.js. Still partial, and the row's own word is the gap: there is no CSV. The rows are a bounded JSON array a caller hands in, capped at 500, with no file upload, no delimiter/encoding/header inference, no column-mapping UI, no streaming and no resumable or scheduled import", "tests": [ "tests/customer-data-foundation.test.js" ], "title": "Import records from CSV", "url": "https://accordo.dev/jobs/jtbd-do-01.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DO-02", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "partially supported", "summary": "deterministic matching under a versioned, fingerprinted policy (deterministic-customer-match@1) with three exact rules in a fixed precedence — external identity, contact email, company name + domain. An exact match reuses the existing record across source systems; ambiguity produces a duplicate-candidate carrying its rule, its evidence and the policy fingerprint, and the row is left unresolved for a person. The scenario earns this by *attempting* an ambiguous row and publishing that no tie was broken. Still partial: nothing fuzzy, phonetic, probabilistic or machine-learned exists, there is no score or threshold, no rule breaks a tie, and detection runs on import only — entering a record by hand through a service or action detects nothing", "tests": [], "title": "Detect duplicates on import or entry", "url": "https://accordo.dev/jobs/jtbd-do-02.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DO-03", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "partially supported", "summary": "on a deliberately narrow reading: a logical canonical merge. A human — never an agent, never without a reason — records that two records are one customer, producing a canonical/alias cluster with the deciding identity and reason on every link. After it, both records still exist byte-identical, both still resolve, both read one consolidated profile, and neither a decided candidate nor an already-clustered record can be silently re-decided or re-parented. Still partial, and the row's own word is again the gap: there is no physical merge. Nothing is deleted, no reference is re-pointed, no field is survivorship-resolved and nothing is un-mergeable by audit — an operator who wants two rows to become one row does not get that here, and it is deliberately deferred to Customer Data Operations v2", "tests": [], "title": "Merge two Companies or Contacts", "url": "https://accordo.dev/jobs/jtbd-do-03.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DO-04", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "partially supported", "summary": "on a deliberately narrow reading: Customer Data Operations v2 adds export-customer-records over the package's eight managed record sets — the import log and its receipts, the identities, the candidates, the links, the findings, the bulk runs and their receipts. The set is counted first with a complete read, the answer states the row count and the bound, a set larger than the bound refuses with EXPORT_WOULD_TRUNCATE instead of returning a short file, at most 10,000 rows, and an export writes nothing. tests/customer-data-operations-v2.test.js. Still partial, and the row's own word is the gap: business records (companies, contacts, opportunities) export through no endpoint, filters are exact-match only, and there is no CSV, no streaming and no scheduled export", "tests": [ "tests/customer-data-operations-v2.test.js" ], "title": "Export records", "url": "https://accordo.dev/jobs/jtbd-do-04.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DO-05", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "partially supported", "summary": "on a deliberately narrow reading: Customer Data Operations v2 adds apply-bulk-customer-action, which applies one of the package's three human decisions — link, dismiss or govern — across up to 500 records in one call, with one transaction and one receipt per record, a run that reads partial rather than completed, and payload-derived idempotency with resume and replay. tests/customer-data-operations-v2.test.js. Still partial, and the row's own word is again the gap: business records have no bulk path — no bulk field update, no bulk stage move, no bulk delete — and every bulked decision keeps its human-only check", "tests": [ "tests/customer-data-operations-v2.test.js" ], "title": "Bulk update a set of records", "url": "https://accordo.dev/jobs/jtbd-do-05.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DO-06", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "not supported", "summary": "no saved-view primitive", "tests": [], "title": "Save and share a filtered view", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DO-07", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "not supported", "summary": "no global search; exact indexed lookups are per-module. Customer Data Foundation v1 builds no search index of any kind and explicitly defers global search to Customer Data Operations v2; its matching is exact lookups on normalized values, which is not search", "tests": [], "title": "Search across modules", "url": "https://accordo.dev/jobs/jtbd-do-07.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DO-08", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "partially supported", "summary": "Work v1 (ADR-030) adds an append-only Activity timeline per subject, with a closed four-entry vocabulary, rendered oldest-first in the Admin — tests/work-operations-e2e.test.js, tests/admin-work.test.js. It is not a unified customer timeline: it covers only what Work itself recorded, Service's support-case-activity stays domain-specific, Delivery history is not aggregated, MK1 proposal evidence is not aggregated and communications events are absent, and no email, call, meeting or audit row appears on it. Customer Data Foundation v1 adds a second, independent projection over the same problem — one read-only consolidated profile per customer, spanning whatever packages the application composes, in which a package that is not composed reads *not available* with a reason rather than as an empty result or a zero. That does not change the row: the profile is a projection over Accordo-managed records, it says so in its own payload, and no email, call, meeting, marketing campaign execution or communications event appears on it. Confirmed *partially supported* by human decision on that wording; no other row is promoted by inheritance from it or from the foundation", "tests": [ "tests/admin-work.test.js", "tests/work-operations-e2e.test.js" ], "title": "See a unified activity timeline for a record", "url": "https://accordo.dev/jobs/jtbd-do-08.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DO-09", "section": "Data operations (Customer Data Foundation v1 — ADR-037, packages/customer-data/README.md)", "status": "not supported", "summary": "no note or attachment primitive", "tests": [], "title": "Attach notes or files to a record", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DS-01", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "validated end to end", "summary": "commercial-contract.create-delivery-handover (human actor only) turns the activated contract's pending delivery obligations into a planned Delivery Project with work packages and milestones, atomically and idempotently, marking exactly those obligations handed over across a package boundary — tests/delivery-handover-e2e.test.js, starter install.mjs. It hands the work over; it does not execute it", "tests": [ "tests/delivery-handover-e2e.test.js" ], "title": "Hand over a won Deal to delivery", "url": "https://accordo.dev/jobs/jtbd-ds-01.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-DS-02", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "partially supported", "summary": "one Delivery Project per activated contract, with one work package per delivery obligation and a milestone plan, each carrying its own snapshot; a project is created from the Contract rather than directly from the Order. M14a adds execution: the project starts, its work packages start, block with a stated reason, resume and complete, and it closes only over completed work — tests/delivery-execution-e2e.test.js. Still no percent complete, scheduling, staffing, cost or billing", "tests": [ "tests/delivery-execution-e2e.test.js" ], "title": "Create a Commessa / Delivery Project from an Order", "url": "https://accordo.dev/jobs/jtbd-ds-02.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DS-03", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "partially supported", "summary": "at most one planned Partner Engagement per project, naming the partner, its role and the work packages it covers, required exactly when work is partner-delivered. It is a business reference and a name snapshot: no account, login, portal, invitation, permission, fee, revenue share or SLA, and multiple partners are not modelled", "tests": [], "title": "Involve a third-party delivery partner (engagement, role, scope)", "url": "https://accordo.dev/jobs/jtbd-ds-03.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DS-04", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "not supported", "summary": "authorization and tenancy now exist, but no partner access surface does: M13 records a partner engagement and grants no access to restrict, and no verifier ships to authenticate a partner (JTBD-15)", "tests": [], "title": "Restrict partner access to assigned work only", "url": "https://accordo.dev/jobs/jtbd-ds-04.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-DS-05", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "partially supported", "summary": "a canonical, ordered milestone plan is created with the project and linked to its work packages, and M14a lets a human start and complete one under a running project. M14b2 adds Deliverables as real objects: planned against a work package and optionally a milestone, completed only from a work package the server says is finished, and immutable once complete. Still nothing schedules or bills a milestone, it is never a contractual milestone, and no file or binary is stored", "tests": [], "title": "Manage milestones and deliverables", "url": "https://accordo.dev/jobs/jtbd-ds-05.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DS-06", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "validated end to end", "summary": "M14b1: append-only time and expense evidence on a running work package, costed server-side by a versioned fingerprinted policy at roundHalfUp(ratePerHourCents × minutes / 60). No public create, update or delete exists on any of it; a client-supplied cost is ignored; internal and partner cost are separable — tests/delivery-economics-e2e.test.js, starter install.mjs. Not payroll, not accounting, and no receipt or invoice is stored or verified", "tests": [ "tests/delivery-economics-e2e.test.js" ], "title": "Track hours and costs on delivery", "url": "https://accordo.dev/jobs/jtbd-ds-06.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-DS-07", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "partially supported", "summary": "M14b1 produces a variance to the latest immutable plan version and a reproducible delivery contribution estimate — the latter only where every commercial input in that currency is one-time. A project carrying a recurring obligation gets contributionBasis: \"unavailable\" with a reason and a null estimate, and its recurring input is preserved as evidence grouped by charge type, interval and interval count. It is deliberately not a margin: no revenue is recognized, no accounting or gross margin is computed, no cost of goods sold exists, no ARR/MRR/TCV or annualization exists, periods are never summed, and currencies are never summed because there is no FX", "tests": [], "title": "Calculate delivery margin (forecast vs actual)", "url": "https://accordo.dev/jobs/jtbd-ds-07.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DS-08", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "validated end to end", "summary": "M14b2: a governed change request with a stated reason, decided exactly once by a human over a declared state table; approving a non-commercial replan creates an immutable versioned Plan Revision, and a commercial change raises an immutable candidate and stops — the suite fingerprints every Quote, Order, Contract and Subscription row before and after and asserts they are byte-identical. The handoff also has a recorded end — a human states what the commercial follow-up concluded elsewhere (resolved_externally or withdrawn), which amends nothing and is what stops a raised candidate blocking the project's acceptance evidence permanently. Admin section, starter journey and 22 real-Chromium checks — tests/delivery-change-acceptance-e2e.test.js, tests/delivery-change-acceptance-integration.test.js, tests/delivery-change-acceptance-evidence.test.js. Not a contract amendment: no Quote/Order/Contract is altered, no amendment record exists, and nothing is priced, quoted or invoiced from the recorded delta", "tests": [ "tests/delivery-change-acceptance-e2e.test.js", "tests/delivery-change-acceptance-evidence.test.js", "tests/delivery-change-acceptance-integration.test.js" ], "title": "Manage a Change Request with impact and approval", "url": "https://accordo.dev/jobs/jtbd-ds-08.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-DS-09", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "partially supported", "summary": "M14b2: Deliverables gated on server-authoritative execution state, and an immutable Acceptance Request that freezes its exact scope with a SHA-256 fingerprint the evidence binds to. A pending request freezes its milestone; a settled scope cannot be re-asked, and the fingerprint covers the body of work alone so retyping the customer label buys no second answer; a rejection preserves completed execution and forces a governed replan over genuinely new work. Partial, and narrowly so: this records what a *user actor* asserted a customer said. It is not an authenticated customer action, not a legal signature, not a verified identity and not authorization to bill — real customer actors are gated by the Production Spine", "tests": [], "title": "Collect customer acceptance on deliverables", "url": "https://accordo.dev/jobs/jtbd-ds-09.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DS-10", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "not supported", "summary": "no billing-milestone primitives", "tests": [], "title": "Activate billing on accepted milestones", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/ADMIN_SMOKE.md" ], "id": "JTBD-DS-11", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "partially supported", "summary": "M15 (merged): a contract's pending Service Obligations are activated by a human into an operational Service Coverage with immutable Entitlements, under a versioned fingerprinted activation policy that refuses rather than guesses when it cannot classify an obligation. SLA targets exist as elapsed wall-clock minutes with recorded evaluations that state the instant and inputs they used, and a package-scoped Admin section drives the whole path — tests/service-operations-e2e.test.js, tests/admin-service.test.js, 24 real-Chromium checks in docs/ADMIN_SMOKE.md, and tests/service-operations-upgrade.test.js for a shipped M12 project adopting it over live obligations. Partial, and narrowly so: a Coverage is *not* a signed contract (nobody signed it, it has no envelope, signer or artifact, and it amends no commercial record), there is no business-hours or holiday calendar, no paused clock, no contractual or legal SLA judgement, no renewal and no billing. The adversarial review narrowed it further before this row was written: the case-evidence keys had to be namespaced and given an occurrence ordinal before the ordinary in_progress ↔ waiting_customer loop could be walked twice at all", "tests": [ "tests/admin-service.test.js", "tests/service-operations-e2e.test.js", "tests/service-operations-upgrade.test.js" ], "title": "Activate a Service Contract with Entitlements and SLA", "url": "https://accordo.dev/jobs/jtbd-ds-11.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-DS-12", "section": "Delivery & Service (handover at M13, execution at M14a, economics at M14b1, and change, deliverables and acceptance at M14b2 — all merged; docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md)", "status": "partially supported", "summary": "M15 (merged): a Support Case recorded against an entitlement over an explicit five-state transition table, with append-only Case Activity, a first response stamped exactly once, and manually recorded Escalation evidence. Entitlement is enforced server-side — an uncovered category, an uncovered priority, an out-of-date coverage or a full open-case limit is refused, and exceeding a limit bills nothing. Not a contact centre: no customer is authenticated, no email, chat, WhatsApp or telephony channel exists, nothing is routed, assigned or escalated automatically, and no attachment is stored", "tests": [], "title": "Manage support cases and escalation", "url": "https://accordo.dev/jobs/jtbd-ds-12.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-LI-01", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "validated end to end", "summary": "with a deterministic fixture provider behind the real provider contract — a real paid external provider is explicitly NOT validated (needs human-approved credentials)", "tests": [], "title": "Enrich a Lead from external sources with snapshot + provenance", "url": "https://accordo.dev/jobs/jtbd-li-01.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-LI-02", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "validated end to end", "summary": "versioned model → ScoreRun + per-rule contributions; reproducible for identical inputs; bounds clamped", "tests": [], "title": "Calculate an explainable lead score", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-LI-03", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "partially supported", "summary": "the managed score exists on every scored lead; no sorted/prioritized list surface exists yet", "tests": [], "title": "Prioritize Leads by score", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-LI-04", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "validated end to end", "summary": "versioned policy → RoutingRun (policy + target-set fingerprints) + per-target route-evaluation evidence + Assignment history; deterministic tie-break; fallback queue; active-workload capacity (released on conversion/disqualification); one final assignment under concurrency incl. a two-connection last-slot race", "tests": [], "title": "Route a Lead automatically under a published policy", "url": "https://accordo.dev/jobs/jtbd-li-04.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-LI-05", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "partially supported", "summary": "declared capacity against ACTIVE workload is enforced (full target excluded; slot released when a lead converts/disqualifies — tested); real availability/calendar data is NOT modeled", "tests": [], "title": "Use sales capacity and availability in routing", "url": "https://accordo.dev/jobs/jtbd-li-05.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-LI-06", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "not supported", "summary": "the assignment record carries source/previousAssignmentId/reason as future data, but no override action exists, and none may claim a manager made the call until a verifier makes that manager a verified person rather than an asserted one (JTBD-15)", "tests": [], "title": "Manually reassign with permission and reason", "url": "https://accordo.dev/jobs/jtbd-li-06.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-LI-07", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "validated end to end", "summary": "narrow wording: publication = code-first registration at startup; each version's fingerprint is persisted in definition_versions; an edited registered version stops the app; no runtime publishing UI", "tests": [], "title": "Version and publish a scoring/routing policy", "url": "https://accordo.dev/jobs/jtbd-li-07.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-LI-08", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "partially supported", "summary": "the mechanism is proven (a new version derived from an earlier definition registers cleanly; history immutable) but no end-to-end starter flow routes with a rolled-back version yet", "tests": [], "title": "Roll back a policy to an earlier version", "url": "https://accordo.dev/jobs/jtbd-li-08.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-LI-09", "section": "Lead Intelligence & Routing (Milestone 9 — implemented for the local slice, ADR-015)", "status": "partially supported", "summary": "runs persist model/policy identity + declared fingerprints, target-set fingerprint, per-target evaluation evidence (in/out, reason, load, capacity, priority) and fingerprints of the mutable lead inputs — but mutable lead-field VALUES are fingerprinted, not copied, and no automated re-execution harness exists", "tests": [], "title": "Reproduce a historical routing decision exactly", "url": "https://accordo.dev/jobs/jtbd-li-09.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-MK-01", "section": "Audience and governance", "status": "not supported", "summary": "MK2; no audience primitive", "tests": [], "title": "Create a dynamic audience from CRM data", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-02", "section": "Audience and governance", "status": "not supported", "summary": "MK2; no snapshot primitive", "tests": [], "title": "Freeze an audience snapshot for a send", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/strategy/DATA_GOVERNANCE.md" ], "id": "JTBD-MK-03", "section": "Audience and governance", "status": "not supported", "summary": "MK2; DATA_GOVERNANCE.md", "tests": [], "title": "Apply exclusions and suppression sets", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/strategy/DATA_GOVERNANCE.md" ], "id": "JTBD-MK-04", "section": "Audience and governance", "status": "not supported", "summary": "MK2; DATA_GOVERNANCE.md — hard", "tests": [], "title": "Verify consent and communication preferences", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-05", "section": "Audience and governance", "status": "not supported", "summary": "MK2; needs campaign history", "tests": [], "title": "Apply a cross-campaign frequency cap", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-06", "section": "Audience and governance", "status": "not supported", "summary": "MK6; no provider adapter", "tests": [], "title": "Sync an audience to a provider", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-07", "section": "Campaign planning", "status": "not supported", "summary": "MK1; funnel primitives, better with Analytics Studio", "tests": [], "title": "Diagnose a funnel drop", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-08", "section": "Campaign planning", "status": "not supported", "summary": "MK1 — the first milestone, and it needs no provider", "tests": [], "title": "Create a complete Campaign Proposal", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-09", "section": "Campaign planning", "status": "not supported", "summary": "MK1/MK2; provider contracts", "tests": [], "title": "Select a channel and an installed provider, with rationale", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-10", "section": "Campaign planning", "status": "not supported", "summary": "MK1", "tests": [], "title": "Recommend a send time and window", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-11", "section": "Campaign planning", "status": "not supported", "summary": "MK3", "tests": [], "title": "Define content, creative, landing page and CTA", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-12", "section": "Campaign planning", "status": "not supported", "summary": "MK3", "tests": [], "title": "Define a tracking plan (UTM, conversion events)", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-13", "section": "Campaign planning", "status": "not supported", "summary": "MK1; real roles need the Production Spine", "tests": [], "title": "Request human approval of a proposal", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-14", "section": "Execution", "status": "not supported", "summary": "MK2; fixture provider first", "tests": [], "title": "Run a one-shot email campaign", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/strategy/JOBS_AND_OUTBOX.md" ], "id": "JTBD-MK-15", "section": "Execution", "status": "not supported", "summary": "MK4; JOBS_AND_OUTBOX.md — hard", "tests": [], "title": "Run a rolling campaign", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-16", "section": "Execution", "status": "not supported", "summary": "MK4; durable event inbox — hard", "tests": [], "title": "Run a triggered campaign", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-17", "section": "Execution", "status": "not supported", "summary": "MK4; scheduler and durable waits — hard", "tests": [], "title": "Run a multi-step multichannel journey", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-18", "section": "Execution", "status": "not supported", "summary": "MK4", "tests": [], "title": "Pause or stop a running campaign", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-19", "section": "Execution", "status": "not supported", "summary": "MK2; inbound provider events", "tests": [], "title": "Handle bounces and unsubscribes", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-20", "section": "Content", "status": "not supported", "summary": "MK3", "tests": [], "title": "Generate email content", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-21", "section": "Content", "status": "not supported", "summary": "MK3", "tests": [], "title": "Generate SMS/WhatsApp messaging content", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/strategy/DESIGN_TO_CRM.md" ], "id": "JTBD-MK-22", "section": "Content", "status": "not supported", "summary": "MK3; design ownership per DESIGN_TO_CRM.md", "tests": [], "title": "Generate a landing page, form and CTA", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-23", "section": "Content", "status": "not supported", "summary": "MK3", "tests": [], "title": "Publish a preview", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-24", "section": "Content", "status": "not supported", "summary": "MK3; human approval mandatory", "tests": [], "title": "Publish an approved asset to production", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-25", "section": "Experimentation", "status": "not supported", "summary": "MK5", "tests": [], "title": "Create an A/B test", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-26", "section": "Experimentation", "status": "not supported", "summary": "MK5; fingerprinted assignment rule", "tests": [], "title": "Assign a deterministic control group", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-27", "section": "Experimentation", "status": "not supported", "summary": "MK5", "tests": [], "title": "Create a holdout", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-28", "section": "Experimentation", "status": "not supported", "summary": "MK5/MK7", "tests": [], "title": "Measure lift against control", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-29", "section": "Experimentation", "status": "not supported", "summary": "MK5; human approval where risk exists", "tests": [], "title": "Select and publish a winner", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-30", "section": "Paid media", "status": "not supported", "summary": "MK6", "tests": [], "title": "Prepare a Media Plan", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-31", "section": "Paid media", "status": "not supported", "summary": "MK6; consent rules", "tests": [], "title": "Sync an audience to an ads platform", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-32", "section": "Paid media", "status": "not supported", "summary": "MK6; human spend approval mandatory", "tests": [], "title": "Launch an approved ads campaign", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-33", "section": "Paid media", "status": "not supported", "summary": "MK6; provider adapters", "tests": [], "title": "Ingest spend and results", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-34", "section": "Paid media", "status": "not supported", "summary": "MK6; a proposal, never an action", "tests": [], "title": "Propose a budget change", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-35", "section": "Analytics and attribution", "status": "not supported", "summary": "MK1/MK7", "tests": [], "title": "Define a funnel", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/strategy/ANALYTICS_STUDIO.md" ], "id": "JTBD-MK-36", "section": "Analytics and attribution", "status": "not supported", "summary": "MK1; ANALYTICS_STUDIO.md", "tests": [], "title": "Identify and segment a drop", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-37", "section": "Analytics and attribution", "status": "not supported", "summary": "MK2 onward", "tests": [], "title": "Report a campaign result", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-38", "section": "Analytics and attribution", "status": "not supported", "summary": "MK7; identity/touchpoint model", "tests": [], "title": "First-touch attribution", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-39", "section": "Analytics and attribution", "status": "not supported", "summary": "MK7", "tests": [], "title": "Last-touch attribution", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [ "docs/strategy/ANALYTICS_STUDIO.md" ], "id": "JTBD-MK-40", "section": "Analytics and attribution", "status": "not supported", "summary": "MK7; ANALYTICS_STUDIO.md — hard", "tests": [], "title": "Multi-touch attribution", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-41", "section": "Analytics and attribution", "status": "not supported", "summary": "MK7", "tests": [], "title": "Connect a campaign to an Opportunity or Order", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-42", "section": "Analytics and attribution", "status": "not supported", "summary": "MK7", "tests": [], "title": "Calculate campaign ROI", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-MK-43", "section": "Analytics and attribution", "status": "not supported", "summary": "MK7; closes the loop", "tests": [], "title": "Recommend the next campaign version", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-PK-01", "section": "Package developer (Custom Package Authoring v1, M13)", "status": "validated end to end", "summary": "a customer-authored package attaches through the identical definePackage contract, works over the generic API, and detaches — with every kernel file fingerprinted before and after to prove no kernel change. One static import composes it; deleting the line removes the surface and leaves the data", "tests": [], "title": "Create and compose a custom local domain package", "url": "https://accordo.dev/jobs/jtbd-pk-01.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-PK-02", "section": "Package developer (Custom Package Authoring v1, M13)", "status": "validated end to end", "summary": "declared capabilities only. packages/delivery reaches packages/contracts through delivery-obligations@1, inside the caller's transaction. An undeclared reach, a wrong declared provider, a missing or mis-versioned dependency and a cycle are all startup failures naming the edge", "tests": [], "title": "Depend on another package without importing its source", "url": "https://accordo.dev/jobs/jtbd-pk-02.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-PK-03", "section": "Package developer (Custom Package Authoring v1, M13)", "status": "partially supported", "summary": "crm package validate|inspect runs the startup validator, reports collisions and private kernel imports, and exits non-zero. It imports and executes the package's own module body: it is not static analysis and not a sandbox", "tests": [], "title": "Validate a package before booting it", "url": "https://accordo.dev/jobs/jtbd-pk-03.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [], "id": "JTBD-PK-04", "section": "Package developer (Custom Package Authoring v1, M13)", "status": "partially supported", "summary": "removing the import removes actions, schema block and Admin section; the tables and rows are left untouched. There is no uninstall, no data migration and no cleanup command — orphaned tables stay orphaned", "tests": [], "title": "Remove a package without losing its data", "url": "https://accordo.dev/jobs/jtbd-pk-04.html", "statusMeaning": "Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it." }, { "docs": [ "docs/plans/dx3-package-scaffold.md" ], "id": "JTBD-PK-05", "section": "Package developer (Custom Package Authoring v1, M13)", "status": "validated end to end", "summary": "accordo package scaffold --apply creates, atomically, a minimal, empty local package — two files, an identity and five empty declarations — dry-run by default, and the result passes package validate, package inspect and package test with no manual edit (tests/package-scaffold.test.js → \"freshly scaffolded output passes validate, inspect and test with no manual edit\"; tests/package-test-command.test.js; docs/plans/dx3-package-scaffold.md). In the same breath, each published as its own limitation code: it invents no business logic — no record, action, policy, provider, capability, Admin section, Solution Plan or MCP tool (NO_DOMAIN_SEMANTICS); it performs no automatic composition — the one import into packages/domains/generated/index.js stays a human's deliberate edit (NO_COMPOSITION); it does no global identity-uniqueness verification — only the target directory is checked, and a duplicate identity is refused later by the registry at startup (IDENTITY_UNIQUENESS_NOT_CHECKED); and it does no remote installation or publication — nothing is downloaded, installed, signed, published or registered anywhere (NO_INSTALL_OR_PUBLISH). Conformance is not correctness: the output satisfies the framework contract and models no domain (CONFORMANCE_IS_NOT_CORRECTNESS)", "tests": [ "tests/package-scaffold.test.js", "tests/package-test-command.test.js" ], "title": "Scaffold a new package from a template", "url": "https://accordo.dev/jobs/jtbd-pk-05.html", "statusMeaning": "An automated test or a checked-in example proves the whole job. This is the only status that counts as evidence." }, { "docs": [], "id": "JTBD-PK-06", "section": "Package developer (Custom Package Authoring v1, M13)", "status": "not supported", "summary": "no registry, publication, remote install, auto-update, signing or hot loading. Packages are checked-in source, by design", "tests": [], "title": "Install a package from a registry or marketplace", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." }, { "docs": [], "id": "JTBD-PK-07", "section": "Package developer (Custom Package Authoring v1, M13)", "status": "not supported", "summary": "and not planned at this layer. Repository source is trusted: a package's module body, actions and policies run in-process with full authority, and the consumer name passed when opening a capability is asserted by the caller (ADR-018 addendum 4)", "tests": [], "title": "Run an untrusted package safely", "url": "https://accordo.dev/jobs/jtbd-pk-07.html", "statusMeaning": "No implementation and no test. It would have to be built. This is the default status in the catalogue — a row moves out of it only when a test proves it." } ], "jobsContract": 1, "statusVocabulary": [ "not supported", "partially supported", "technically supported", "validated end to end" ], "sourceVisibility": { "repository": "https://github.com/khaoss85/agent-crm", "note": "Evidence paths resolve in the public repository." } }