{
  "example_kind": "invented job and manual worksheet",
  "slug": "parallel-ownership-split",
  "title": "Let two contributors help without creating two competing final versions",
  "layout": "handover",
  "story": "When two people change the same artifact independently, I want clear contribution boundaries and one integration owner so the receiver gets one coherent result.",
  "problem": "Two writers improve an operating guide. Their exception wording conflicts because both assume they own the final procedure.",
  "symptoms": [
    "Both contributors produce a final version.",
    "Shared terminology changes without an integration decision.",
    "The receiver must resolve conflicts that the team should have settled."
  ],
  "failed_workaround": "Adding both names as owners does not explain who merges the result or decides which conflicting wording governs.",
  "before": "Both writers own the guide. Send whichever version looks finished first.",
  "after": "Contribution agreement: one writer owns procedure sections; the other owns examples. The integration owner reconciles exception wording and terminology into one review version. Both contributors inspect the assembled guide before the receiving owner reviews it. Neither draft independently becomes the final operating instruction.",
  "success_check": "The receiver gets one agreed review version and can identify who resolves conflicts between contributions.",
  "choices": [
    [
      "Contributions are separable",
      "Assign distinct output boundaries",
      "Parallel work can proceed without duplicate final ownership."
    ],
    [
      "Contributions change shared meaning",
      "Set the integration decision first",
      "Conflicting definitions cannot be reconciled by arrival time."
    ],
    [
      "The assembled output is incoherent",
      "Keep receiving review pending",
      "Completion of separate tasks does not prove a coherent deliverable."
    ]
  ],
  "route": [
    {
      "label": "Separate contribution work",
      "capability": "task-record",
      "action": "Assign procedure and example tasks to their contributors.",
      "human_check": "Each assignment has an agreed output boundary."
    },
    {
      "label": "Preserve integration decisions",
      "capability": "task-comment",
      "action": "Record the exception wording choice and one review version.",
      "human_check": "A human resolves the conflicting meanings."
    },
    {
      "label": "Report the coherent delivery stage",
      "capability": "daily-report",
      "action": "Describe contribution progress separately from assembled-guide readiness.",
      "human_check": "The receiver reviews the coherent result, not two incompatible drafts."
    }
  ],
  "editor": {
    "heading": "Prepare a receiving brief",
    "fields": [
      {
        "key": "parta",
        "label": "First contribution",
        "example": "Procedure sections",
        "help": "Name a bounded contribution."
      },
      {
        "key": "partb",
        "label": "Second contribution",
        "example": "Examples matching the procedure",
        "help": "Make the overlap or dependency explicit."
      },
      {
        "key": "integrator",
        "label": "Integration owner",
        "example": "Guide coordinator",
        "help": "Who owns the assembled result?"
      },
      {
        "key": "conflict",
        "label": "Shared decision to resolve",
        "example": "Exception terminology",
        "help": "Name the issue drafts disagree on."
      },
      {
        "key": "check",
        "label": "Assembly check",
        "example": "Both writers inspect one version before receiving review",
        "help": "Use a coherence check, not a file count."
      }
    ],
    "template": "Parallel-work agreement\nContribution A: {parta}.\nContribution B: {partb}.\nIntegration owner: {integrator}.\nShared decision: {conflict}.\nBefore receiving review: {check}.\nOnly the agreed assembled version is the receiving artifact."
  },
  "limitations": "The example does not implement merging or native multi-owner approval. Task relationships and receiving checks need account/process confirmation.",
  "tasks": [
    [
      "Define the contribution boundaries",
      "Coordinating lead",
      "Procedure sections and examples have distinct contributor responsibilities."
    ],
    [
      "Own the assembled result",
      "Integration owner",
      "One review version resolves conflicting exception wording."
    ],
    [
      "Check coherence before receiving review",
      "Contributors",
      "Examples agree with the procedure and both contributors inspect the assembled guide."
    ]
  ],
  "faqs": [
    [
      "Does this require just one contributor?",
      "No. Parallel contribution can help when the integration responsibility is explicit."
    ],
    [
      "Who decides a shared terminology conflict?",
      "Use the agreed integration/receiving route rather than whichever draft arrived first."
    ],
    [
      "How should we track it in TeamBoost?",
      "Use distinct owned tasks for contributions and a separate integration task or clearly recorded integration responsibility. Confirm the task relationships available in your account."
    ]
  ]
}