customer-delivery

Files (1)

• SKILL.md

SKILL.md (first lines)

# Customer Delivery

A user-facing requirement is delivered only when a verbatim customer statement
flows through pinned knowledge, an implementation delta, red/green evidence, a
merged revision, a deployed revision, live production evidence, and an explicit
operator visual disposition — in that order, with no missing edge.

Enabling artifacts — tools, documentation, tests, CI runs, ledger entries,
receipts — support closure but never substitute for it.

## U1. Verbatim atomic requirements

- Store every customer remark verbatim; a paraphrase is metadata, never the
  source of truth.
- Decompose each remark into atomic, stable Requirement IDs.
- Corrections are append-only: record the superseding statement and retain the
  superseded one.

**Fail** if a requirement cites a paraphrase, an aggregate summary, or an
unstable ID as its origin.

## U2. Acceptance tuple

Every Requirement ID carries:

- originating source and exact quotation;
- affected product and surface or route (surface class);
- locale, viewport, and theme dimensions when applicable;
- observable before-state and required after-state;
- evidence method and responsible owner;
- applicable role, skill, blueprint, constraint, policy, and success criterion;
- delivery task, code/content paths, and target environment;
- customer disposition: pending, accepted, rejected, or superseded;
- visibility classification: enabling or visitor-visible;
- receipt pointer to its coverage receipt.

Bind expectations through schema v4 by declaring `customer_derived` on every
wish. A `true` declaration carries the Requirement ID, surface class,
visibility, and receipt pointer; a `false` declaration carries none of those
four fields.

At least one acceptance criterion must assert an observable visitor-facing
change on the live production product. A rendered test-environment comparison
is mandatory supporting evidence but cannot replace the live result.

**Fail** if a user-facing requirement is satisfied only by knowledge,
documentation, test, CI, or ledger output.

## U3. Pre-work knowledge pinning

- The applicable knowledge is selected before implementation starts. Before
  `implementation_started_at`, the issued contract pins current
  admissible revisions of the applicable role, skill, blueprint, constraint,
  policy, and success criterion — each with an immutable revision, digest, and
  timestamp.
- `Gap` or `Unbound` may authorize research or capability creation but may
  never be represented as blueprint-applied product delivery.
- Selection after implementation start is post-hoc attribution and fails.
- Carry the selected bindings and task-relevant evidence into delegated or
  isolated stages through approved readable references or a sanitized bundle;
  a parent-only conversation or inaccessible host path is not inherited context.
  Preserve the original selection time, revision and digest, and distinguish
  evidence measured on a named environment/revision at its observation time
  from inferred claims. Verify availability before affected work; missing
  material remains an explicit gap, not permission to reconstruct protected
  originals or invent a prior selection.
- Inherited measurements are historical evidence, not fresh verification of
  the current target. Preserve original `verified:` / `assumed:` provenance
  metadata and apply the replay downgrade and revalidation rules in
  `${DATARIM_RUNTIME:?}/skills/session-handoff-writer/SKILL.md` and
  `${DATARIM_RUNTIME:?}/skills/session-handoff-replay/SKILL.md`; a copied receipt,
  matching document digest, or rewritten timestamp cannot refresh a live check.
- For classified sensitive sources, use the existing constraints/policies selection to pin the task's metadata-only sanitized binding, following `${DATARIM_RUNTIME:?}/skills/security/SKILL.md` § Sensitive source context boundary. Record its revision, digest and actual selection time before future affected reads or work. A classification discovered during work must be preserved prospectively; this does not establish retroactive pre-work compliance or clear an earlier missing-selection failure.

**Fail** if any required knowledge kind is missing, `Gap`/`Unbound` stands in
for a delivery-bound contract, or a revision is selected after work began.

## U4. Coverage receipt

Emit a machine-readable acyclic mapping per delivery:

`Requirement -> selected knowledge revisions -> implementation delta ->
red/green evidence -> merged revision -> deployed revision -> live evidence ->
customer disposition`

- A missing edge means `NOT MET`.
- Receipts are deterministic and mutation tested: removal of any required edge
  must turn the gate red.

**Fail** on a cycle, a missing edge, a mutable revision reference, or a receipt
that cannot fail when an edge is removed.

## U5. Closure semantics

A user-facing task or epic cannot close while:

- any originating customer review is open or changes-requested;
- any required live evidence is absent;
- production is behind the accepted revision; or
- operator visual acceptance is pending.

Executable rules, not guidance:

- `green CI != deployed`
- `deployed != visually accepted`
- `enabling work != customer outcome`

Epic state is derived from the Requirement graph and child acceptance states,
never from an independently authored prose status.

**Fail** if a task closes on CI, merge, or internal review alone.

## U6. Review-to-evolution

Classify every review finding exactly one of:

`ABSENT`, `WEAK`, `STALE`, `MIS_SCOPED`, `NOT_BOUND`, `NO_CANON_CHANGE`

- The first five require an artifact revision or new artifact plus a

From Arcanada-one/datarim, MIT.

More from Arcanada-one/datarim