Search documentation

Browse Awaken Workforce docs
Docs/Awaken Workforcev0.1.0/Internal mechanisms/Contribute and extendContribute and extend Awaken Workforce
Note·You're reading pre-release documentation (v0.1.0). Interfaces and behavior may change before a stable release.

Internal mechanisms · Contribute and extend

Contribute and extend Awaken Workforce

What this page covers

Choose the authoritative bounded context, reuse its ports, and preserve Workforce's mechanically enforced invariants.

Extend Awaken Workforce by changing the one authoritative owner of a behavior. Do not introduce a second Resource, Workflow, Agent, event append, authorization, or execution mechanism.

Static ownership

ChangeAuthoritative ownerExtension seam
Domain rule or objectpurpose-named domain cratecommand/repository ports and facts owned by that context
Lease, wake, provision, execution, egressruntime cratenarrow mechanism port
Persistence, IAM, MCP, Pack distributionadapter cratedomain-defined port / anti-corruption layer
HTTP, process topology, backend selectionapp crateassembly over lower layers
Agent executionAwaken through awaken-flow-runtimethe single Runtime ACL; never a parallel executor

Dependencies point downward: lib → domain → runtime → adapter → app. An app may compose lower layers; a lower layer must never import product, transport, or persistence vocabulary from above.

Change workflow

  1. Read the source repository’s architecture overview, invariant registry, and requirements-coverage owner for the change.
  2. Search code, tests, public API snapshots, and ADRs for an existing mechanism.
  3. Extend the authoritative implementation and migrate all callers; remove any competing path before continuing.
  4. Add or amend an ADR only for a contested, cross-crate, or invariant-reaching decision.
  5. Name the enforcer and validation for every new guardrail.
  6. Update the public API snapshot when the change is deliberately public.
  7. Run scripts/ci/check-docs.sh and scripts/ci/check-all.sh.

Dynamic write path

flowchart TD
  Command[Authorized command] --> Validate[Owner validates expected version]
  Validate --> Stage[Unit of work stages owner facts]
  Stage --> Commit[One append mechanism commits]
  Commit --> Replay[Projections replay committed facts]
  Replay --> Reaction[Runtime reaction may schedule work]
  Reaction --> Effect[Adapter performs fenced external effects]

Failures before commit produce no partial domain truth. Live effects use leases, idempotency, reconciliation, or checkpoint boundaries appropriate to their mechanism; retry must not invent a second business decision.

Start with architecture and vocabulary, Workforce–Awaken execution ownership, and testing a Domain Pack. The source repository’s ADRs and invariant registry remain the design authority; this page is a contributor route, not a duplicate architecture corpus.