| name | company-work-operator |
| description | Inspect and route authoritative TeamWork through the Company Work aggregate, and manage Company Milestone or Approval references without creating a second task or assignment object. |
Company Work Operator
This skill is procedural guidance, not product authority. The native TeamWork contract, Store validation, and Human governance decisions remain authoritative.
Use Company Work as a company-wide read, filter, and routing surface over
authoritative TeamWork. The shorthand work is acceptable only when the
execution or Company context is explicit.
The core invariant is:
Company Work row id + revision == authoritative TeamWork id + revision
Never copy a TeamWork into a Company-owned task record. Never dual-write
lifecycle, responsibility, delivery, evidence, or status.
Authority boundary
TeamWork owns:
- identity and revision;
- Team and TeamRun scope;
- parent/prerequisite relationships;
- owner and eligible members;
- phase, condition, and resolution;
- context and completion criteria;
- immutable reports, gate evaluations, operational decisions, events, evidence,
artifacts, checks, and external links;
- delivery and provider runtime bindings.
Company OS owns only company context that refers to TeamWork:
Milestone.work_refs;Approval.subject_ref(kind=work);- Business Module or Docs relations that point to Work;
- Company-wide filters, summaries, boards, and routing links.
Company OS does not own a second task ledger, assignment ledger, lifecycle, or
execution bridge.
Lifecycle contract
Treat the three axes independently:
- phase:
open | active | review | closed;
- condition:
normal | blocked | on_hold;
- resolution:
accepted | cancelled | failed, present only when phase is
closed.
Blocking or pausing preserves phase. Delivery state, gate state, and provider
runtime state are independent and must not be inferred from phase.
A Work is accepted only when:
phase = closed AND resolution = accepted
The accountable member cannot self-accept. Acceptance must follow the
authoritative chain:
WorkReport -> Evidence -> GateEvaluation / Verification
-> OperationalDecision -> WorkEvent
Every report and decision must bind the exact Work id and revision being
evaluated.
Select stores explicitly
Company reads need a Company Store; TeamWork mutations need an Execution Space.
Select both explicitly when they differ:
harness company current
harness project current
harness work list
harness --space <space-id> team-run work list --team-id <team-id>
Do not rely on the current directory to imply either authority.
Read and filter Global Work
The Global Work view (DOC-106) is the one read projection over the canonical
Work/WorkOperation authority. It replaces the retired company work list/query CLI and /v1/views/company-work endpoint.
harness work list
harness work list --team-id <team-id>
harness work list --assignee-membership-id <membership-id>
harness work list --assignee-kind <host|member|unassigned>
harness work list --member-id <agent-member-id>
harness work list --phase <open|active|review|closed>
harness work list --condition <normal|blocked|on_hold>
harness work list --resolution <accepted|cancelled|failed>
harness work list --priority <low|normal|high|urgent>
The same projection is served at GET /v1/views/global-work. Responsibility
follows the assignee TeamMembership, never a MemberRun or runtime state.
These commands are read-only. They return the original TeamWork records without
fallback rows or copied Company lifecycle fields.
Route mutations to TeamWork
Company Work mutation commands do not exist. Use the authoritative execution
surface:
harness team-run work create --team-run-id <run-id> --title <title> \
--completion-criteria <criteria>
harness team-run work assign --team-run-id <run-id> --work-id <work-id> \
--member-run-id <member-run-id> --expected-version <version>
harness team-run work start --team-run-id <run-id> --work-id <work-id> \
--expected-version <version>
harness team-run work block --team-run-id <run-id> --work-id <work-id> \
--reason <reason> --expected-version <version>
harness team-run work resume --team-run-id <run-id> --work-id <work-id> \
--expected-version <version>
harness team-run work submit --team-run-id <run-id> --work-id <work-id> \
--summary <summary> --expected-version <version>
harness team-run work request-changes --team-run-id <run-id> --work-id <work-id> \
--reason <reason> --expected-version <version>
harness team-run work accept --team-run-id <run-id> --work-id <work-id> \
--expected-version <version>
harness team-run work cancel --team-run-id <run-id> --work-id <work-id> \
--reason <reason> --expected-version <version>
Always re-read the Work after a conflict. Do not retry a mutation using a stale
version.
Milestones and approvals
Milestones group authoritative Work ids without replacing their identity:
harness company work milestone list
harness company work milestone show --milestone <milestone-id>
harness company work milestone create \
--authority <human-admin-id> \
--id <milestone-id> \
--title <title> \
--outcome <outcome> \
--accountable-owner <actor-id> \
--work <work-id>
harness company work milestone update \
--authority <human-admin-id> \
--milestone <milestone-id> \
--work <work-id>
An Approval governing Work uses subject_ref.kind = work and the exact
authoritative Work id. Approval decisions do not mutate Work directly; the
authorized actor still performs the native Work operation.
Docs, Finance, gateways, and GitHub
Docs may embed or relate to EntityRef(kind=work), but must not copy Work
phase or completion truth into prose.
Finance owns Commitments and Payments. A Work may be their governed subject or
context through explicit relations, but a Work decision never implies payment.
Gateway and connector observations become context, evidence, or external links.
They do not create a parallel task model. GitHub Issue, PR, commit, check,
review, and release state remain external facts; they may satisfy criteria but
do not close Work without an operational decision.
Safe workflow
- Resolve the Company Store and Execution Space explicitly.
- Read the authoritative Work and its current version.
- Inspect Team, TeamRun, owner, prerequisites, criteria, gates, and condition.
- Route any mutation to
team-run work.
- Attach immutable reports and evidence to the exact candidate revision.
- Keep gate, delivery, and runtime state independent.
- Use Milestone, Approval, Docs, or Finance references only for their owning
system's context.
- Re-read the exact Work revision after mutation.
- Report the original Work id, new version, lifecycle axes, evidence, decision,
and remaining blockers.
Validation checklist
- No Company-owned duplicate task or assignment row was created.
- Company projection preserves original Work ids and revisions.
- Non-closed Work has no resolution.
- Closed Work has condition
normal and exactly one resolution.
- Blocked or on-hold Work preserves its phase.
- Report, evidence, gate evaluation, decision, and event bind the same Work
revision.
- The accountable member did not self-accept.
- Milestone and Approval reference
work, not a copied record.
- Mutation used a current expected version and the native TeamWork surface.
- External facts remain linked evidence rather than lifecycle authority.
Report format
State:
- authoritative Work id and version;
- Team and TeamRun;
- phase, condition, and resolution;
- owner and eligible members;
- report/evidence/gate/decision refs;
- Milestone, Approval, Docs, Finance, and external refs;
- mutation command used, if any;
- remaining blockers or missing cross-space visibility.
