{
  "id": "page:library-collaboration",
  "_kind": "Page",
  "_file": "wiki/library/collaboration.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "title": "collaboration (Library)",
    "displayName": "collaboration (Library)",
    "slug": "library/collaboration",
    "articlePath": "wiki/library/collaboration.md",
    "article": "\n# collaboration\n\nPR and issue collaboration policy processes, plus the code-review rubrics the PR\nlifecycles call. Everything here is about how a change moves through review: the policy\ngates a PR must satisfy, the lifecycle variants that compose those gates for different\nkinds of change, and the structured review rubrics that produce the verdict.\n\n## Layout\n\n- `code-review/` — 2 processes (review rubrics).\n- `github/` — 16 processes (lifecycles, policy gates, utilities).\n\nThere are deliberately no root-level `.js` files in this specialization.\n\n## code-review/\n\n- `six-dimension-review.js` (`@process specializations/collaboration/code-review/six-dimension-review`)\n  — Structured PR review across six dimensions: correctness, clarity, consistency,\n  coverage, complexity, change-scope.\n- `validator.js` (`@process specializations/collaboration/code-review/validator`)\n  — Multi-dimensional PR validator. Runs six review dimensions in parallel (quality,\n  architecture, tests, security, UX, business), materialises non-blocking findings as a\n  deferred-debt filesystem (`docs/validation/<id>/<priority>/<category>/NN-title.md`),\n  then posts an approve-or-request-changes verdict.\n\n**These two carry DIFFERENT dimension sets and are not interchangeable.**\n`six-dimension-review.js` hardcodes `correctness, clarity, consistency, coverage,\ncomplexity, change-scope`; `validator.js` hardcodes `quality, architecture, tests,\nsecurity, ux, business`. Both happen to be six dimensions; that is the only thing they\nshare. Picking one over the other is a real choice, not a naming detail. Reconciling the\ntwo rubrics is an open item, not something this README papers over.\n\n## github/\n\n### Entry point\n\n- `pr-lifecycle-router.js` (`@process specializations/collaboration/github/pr-lifecycle-router`)\n  — Dispatches to the appropriate pr-lifecycle variant based on (event x inferred change\n  type). One entry point; many lifecycles.\n\n### Lifecycle variants\n\n- `pr-lifecycle-feature.js` (`@process specializations/collaboration/github/pr-lifecycle-feature`)\n  — Standard feature/bugfix/chore PR lifecycle: branch+PR policies -> label taxonomy ->\n  issue linking -> six-dimension review -> merge gate. Composes the individual gate\n  processes into one end-to-end flow.\n- `pr-lifecycle-hotfix.js` (`@process specializations/collaboration/github/pr-lifecycle-hotfix`)\n  — Fast-path lifecycle for production hotfixes: minimal gates, mandatory incident link,\n  on-call sign-off breakpoint, merge to main + backport to staging/develop.\n- `pr-lifecycle-docs.js` (`@process specializations/collaboration/github/pr-lifecycle-docs`)\n  — Docs-only PR lifecycle: verify docs-only scope -> link check -> style/voice audit ->\n  technical-accuracy review (if touching technical docs) -> merge.\n- `pr-lifecycle-security.js` (`@process specializations/collaboration/github/pr-lifecycle-security`)\n  — Security PR lifecycle: embargo check -> restricted-reviewer gate -> confidentiality\n  audit (no leaks in title/body/tests/diff) -> coordinated disclosure plan -> merge window.\n- `pr-lifecycle-dependency-bump.js` (`@process specializations/collaboration/github/pr-lifecycle-dependency-bump`)\n  — Dependency-bump (dependabot/renovate) lifecycle: verify lock-file-only change ->\n  classify semver impact -> require green CI -> auto-merge patch/minor, require human\n  approval for major.\n- `pr-lifecycle-comment-response.js` (`@process specializations/collaboration/github/pr-lifecycle-comment-response`)\n  — Lifecycle triggered by @mention on a PR comment: classify intent -> route to\n  review-comment-response OR re-run a targeted gate -> post reply with fix commit ref.\n\n### Policy gates\n\n- `branch-policies.js` (`@process specializations/collaboration/github/branch-policies`)\n  — Enforce branch-naming, target-branch, and no-direct-push-to-protected rules.\n- `pr-policies.js` (`@process specializations/collaboration/github/pr-policies`)\n  — Enforce PR hygiene: title conventions, scope, description completeness, linked issues,\n  reviewers.\n- `draft-pr-policy.js` (`@process specializations/collaboration/github/draft-pr-policy`)\n  — Prohibit draft PRs for ready-to-merge flows; require ready-for-review state before\n  CI/review gates apply.\n- `label-taxonomy.js` (`@process specializations/collaboration/github/label-taxonomy`)\n  — Enforce a canonical label taxonomy (type/area/priority) on issues and PRs.\n- `issue-linking.js` (`@process specializations/collaboration/github/issue-linking`)\n  — Ensure PRs and commits link to tracking issues with proper closing keywords.\n- `issue-only-no-direct-commits.js` (`@process specializations/collaboration/github/issue-only-no-direct-commits`)\n  — Every non-trivial commit must trace to an issue; direct commits without an issue\n  reference are rejected in CI.\n\n### Utilities\n\n- `conflict-resolver.js` (`@process specializations/collaboration/github/conflict-resolver`)\n  — Merge-conflict resolver. Detects conflicts, checks whether upstream already covers the\n  PR (safe-close if so), otherwise rewrites the PR branch in place: rebase onto base,\n  resolve each conflict category, verify locally, force-push-with-lease, re-invoke\n  validator. Works DIRECTLY on the existing PR branch — never creates a new branch/PR.\n- `pr-comment-response.js` (`@process specializations/collaboration/github/pr-comment-response`)\n  — Respond to a PR review comment: classify intent, address the concern, post a reply\n  linking the fix commit.\n- `producer.js` (`@process specializations/collaboration/github/producer`)\n  — Producer persona. Detects project phase -> ingests spec (`docs/specs/README.md`) ->\n  extracts gaps vs current implementation -> dedupes against existing issues -> drafts\n  issue bodies in parallel -> infers labels/assignees -> batch-creates GitHub issues.\n  Optionally runs a tech-debt scan grouping `docs/validation/` findings into\n  implementation issues.\n\n## Composition\n\n`pr-lifecycle-router.js` is the single entry point: it dispatches by event and inferred\nchange type to one of the six `pr-lifecycle-*` variants. The lifecycle variants in turn\ncompose the policy gates and the review rubric — `pr-lifecycle-feature.js` composes\nbranch-policies, pr-policies, label-taxonomy, issue-linking, and\n`code-review/six-dimension-review.js` into one end-to-end flow. The other variants select\na narrower or wider set of the same gates to match the risk profile of the change.\n\n## Assets\n\n- Skill: [`skills/six-dimension-code-review/SKILL.md`](./skills/six-dimension-code-review/SKILL.md)\n  — the canonical six-dimension review rubric.\n- There are no agents in this specialization.\n\n---\n\nDescriptions in this README are transcribed from the files' own `@description` headers,\nnot invented.\n",
    "documents": [
      "specialization:collaboration"
    ]
  },
  "outgoingEdges": [
    {
      "from": "page:library-collaboration",
      "to": "specialization:collaboration",
      "kind": "documents"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:index",
      "to": "page:library-collaboration",
      "kind": "contains_page"
    }
  ]
}