@pmcollab/coworkstream-details-hr

Fork-friendly HR templates for @pmcollab/coworkstream: hiring pipeline plus 8 offboarding categories.

These are starting templates, not stable APIs. Almost every customer should fork them.

What's included

| Component | Category | Renders | |---|---|---| | HiringDetails | hiring | Pipeline stages, candidate count, agent autonomy, role template | | ResignationDetails | resignation | Notice period, last day, transition checklist | | TerminationDetails | termination | Termination type, severance, blocker tasks | | KnowledgeTransferDetails | knowledge-transfer | KT areas, recipients, completion | | AccessRevocationDetails | access-revocation | System list, revocation status, exceptions | | EquipmentRecoveryDetails | equipment-recovery | Asset list, return logistics | | ExitProcessDetails | exit-process | Exit interview, signed paperwork | | TeamRebalanceDetails | team-rebalance | Workload reassignment to teammates | | LegalHoldDetails | legal-hold | Hold reason, retention period, custodian list |

Plus default taxonomy data:

import {
  HIRING_STAGE_ORDER, ROLE_TEMPLATES, AVAILABLE_AGENTS, AUTONOMY_LEVELS,
  OFFBOARDING_TYPES, ASSET_TYPES, KNOWLEDGE_TRANSFER_AREAS,
} from '@pmcollab/coworkstream-details-hr'

Install

npm install @pmcollab/coworkstream-details-hr

Use as-is (evaluation only)

import { WorkStream } from '@pmcollab/coworkstream'
import {
  HiringDetails, ResignationDetails, /* ... */
} from '@pmcollab/coworkstream-details-hr'

const renderDetails = (item) => {
  switch (item.category) {
    case 'hiring':              return <HiringDetails item={item} />
    case 'resignation':         return <ResignationDetails item={item} />
    case 'termination':         return <TerminationDetails item={item} />
    // ...
    default:                    return null
  }
}

<WorkStream items={items} renderDetails={renderDetails} />

This works for evaluation. Interactive bits are no-ops because no stores are wired.

Fork them

See FORKING.md. Recommended pattern:

1. Copy the components you want into src/components/hr/Contoso*.jsx.
2. Replace from './_fork-stubs' imports with your real stores/toast.
3. Replace _fork-data-onboarding.js / _fork-data-offboarding.js with your company's hiring stages, role templates, and offboarding terminology.
4. Rename exports (HiringDetails → ContosoNewHire).
5. Wire your forked components into renderDetails and stop importing from this package.

You now own them. We can change anything in the next major; your fork is safe.

Why fork-only and not "just use the package"?

HR is the most domain-specific surface in any product. Our hiring pipeline has 7 stages because that's what the host modeled; yours might have 4 or 12. Our offboarding flow includes legal hold, knowledge transfer, asset recovery, etc., in a specific order — you might bundle differently. Trying to make a single package serve every HR taxonomy via props is a path to a 200-prop component nobody understands.

The fork model gives you:

• A working starting point so you don't design from blank
• Full control over what stays and goes
• Stability — your fork doesn't move when we ship v0.2

License

Commercial. See LICENSE in the repository root.