{
  "example_kind": "invented job and manual worksheet",
  "slug": "task-ownership-versus-approval",
  "title": "Pass the business receiving check after the technical tests pass",
  "layout": "handover",
  "story": "When technical tests pass but the business meaning remains unclear, I want the receiving expert to check specific examples so the implementation owner gets a bounded correction rather than a vague approval request.",
  "problem": "An engineer owns a billing-view change and passes unit checks. Finance still needs to judge whether partial refunds are recognizable in the finished view.",
  "symptoms": [
    "One owner name is expected to cover production and receiving acceptance.",
    "Internal checks are treated as customer or business approval.",
    "A reviewer is involved only after the work is called done."
  ],
  "failed_workaround": "Adding more technical checks does not replace the receiver’s judgment about the required business meaning.",
  "before": "Engineering owns the billing view, so passing unit tests closes the work.",
  "after": "Responsibility agreement: engineering owns the implementation and technical checks. Finance reviews full, zero and partial-refund examples for recognizability. The partial-refund example needs clarification, so delivery acceptance remains open. Engineering keeps the delivery task; Finance supplies the receiving verdict rather than becoming an unrequested implementer.",
  "success_check": "Finance can identify the partial-refund interpretation gap in specific examples, while engineering retains correction ownership and receives an agreed recheck.",
  "choices": [
    [
      "Delivery and acceptance require different expertise",
      "Name both responsibilities",
      "Technical completion and business suitability are different claims."
    ],
    [
      "The receiver identifies one gap",
      "Return that bounded correction",
      "Do not transfer the whole implementation responsibility accidentally."
    ],
    [
      "The real process permits one person to cover both",
      "Record the permitted boundary",
      "The workflow should reflect actual authority, not a universal separation rule."
    ]
  ],
  "route": [
    {
      "label": "Assign the producing work",
      "capability": "task-record",
      "action": "Keep the engineer responsible for the implementation task.",
      "human_check": "Confirm the assignment reflects an agreed responsibility."
    },
    {
      "label": "Write the acceptance request",
      "capability": "task-comment",
      "action": "Record Finance’s receiving question and the three review examples.",
      "human_check": "A human reviewer judges whether the result meets that meaning."
    },
    {
      "label": "Explain the remaining state",
      "capability": "daily-report",
      "action": "Report technical checks passed and Finance clarification still open.",
      "human_check": "Do not summarize the two boundaries as an unqualified done."
    }
  ],
  "editor": {
    "heading": "Prepare a business receiving check",
    "fields": [
      {
        "key": "deliverer",
        "label": "Delivery owner",
        "example": "Engineering owner",
        "help": "Who produces the result?"
      },
      {
        "key": "receiver",
        "label": "Acceptance reviewer",
        "example": "Finance reviewer",
        "help": "Who judges the receiving meaning?"
      },
      {
        "key": "boundary",
        "label": "Acceptance question",
        "example": "Can full, zero and partial refunds be recognized?",
        "help": "Use a concrete question, not approve everything."
      },
      {
        "key": "proof",
        "label": "Example or evidence",
        "example": "Three refund examples; partial-refund case needs clarification",
        "help": "Keep the actual receiving evidence."
      },
      {
        "key": "next",
        "label": "Return check",
        "example": "Finance rechecks the clarified partial-refund example",
        "help": "Agree how the gap closes."
      }
    ],
    "template": "Business receiving check\nImplementation owner: {deliverer}.\nReceiving expert: {receiver}.\nBusiness meaning to check: {boundary}.\nWorked examples and unresolved gap: {proof}.\nCorrection return and recheck: {next}.\nPassing technical tests does not settle this separate receiving judgment."
  },
  "limitations": "The example does not establish a TeamBoost approval-role feature or general governance rule. Confirm the actual receiving process.",
  "tasks": [
    [
      "State production responsibility",
      "Delivery lead",
      "Engineering owns implementation without inheriting Finance’s acceptance role."
    ],
    [
      "Agree receiving examples",
      "Finance reviewer",
      "Full, zero and partial-refund examples exercise the actual business question."
    ],
    [
      "Return the bounded gap",
      "Engineering owner",
      "The partial-refund correction is linked to Finance’s evidence and recheck."
    ]
  ],
  "faqs": [
    [
      "Does naming a reviewer mean they own implementation?",
      "No. Make production responsibility and acceptance responsibility explicit."
    ],
    [
      "Can the delivery owner also accept?",
      "Sometimes, if the real process permits it; this example requires a separate Finance judgment."
    ],
    [
      "Where does this fit in TeamBoost?",
      "Use the documented task assignment for delivery ownership and the task context to record the receiving role and agreed examples. Do not assume there is a separately configured native approval role."
    ]
  ]
}