donniedice

WORKFORCE BY DONNIEDICE

The backlog.
A workforce
behind it.

Specialized AI roles connected to GitLab work. Route the task, get changes back for review, and keep responsibility with the operator.

See how it works →Explore the roles ↗

Built by donniedice. Running within DiceMatrix. Internal use only.
Not for sale or distribution. No new orders or payments accepted.

WORKFORCE ARCHITECTURE 8 ROLES
◇ GitLab backlog ISSUE →
⌘
DispatcherTriage · scope · route
COORDINATE
02Engineer
03QA
04Reviewer
05Security
06Platform
07Release
08Docs
Merge request + evidenceReview gates
INTERNAL INFRASTRUCTURE ILLUSTRATIVE FLOW / NOT LIVE ACTIVITY
08Specialist rolesSeparate identities & responsibilities
GitLabCanonical work queueScope, assignments, and evidence
ReviewBefore releaseExplicit permissions and human gates
InternalBuilt by donniediceRunning within DiceMatrix

01 THE PROJECT

The setup supports the work.
The responsibility stays human.

An internal foundation for coordinating technical work. Role separation, infrastructure, and review evidence belong together—not behind a promise of unattended delivery.

A delivery workflow,
not another chat window.

Move from a scoped GitLab issue to a task branch, tests, and a merge request. Keep assignments and completion evidence alongside the code.

ISSUE → WORK → REVIEW

Boundaries that matter

Separate identities and role-scoped permissions. Implementation and independent review are different responsibilities.

Infrastructure as code

Configuration, deployment boundaries, and operating policy are maintained as code, with explicit authorization for changes.

Evidence, not assumptions

An assignment is not execution. A passing mock is not a live result. Verify what actually happened.

Know the boundary. This is private internal infrastructure—not a hosted service, a public software package, or a guarantee of autonomous delivery.

02 FROM ISSUE TO REVIEW

A scoped task.
A result to inspect.

  1. 01

    Define the work

    Record the outcome, acceptance criteria, allowed scope, and checks in GitLab.

  2. 02

    Route responsibility

    Separate coordination, implementation, independent checks, and release authority.

  3. 03

    Implement & verify

    Produce changes, tests, and evidence. Report missing access or uncertainty instead of inventing results.

  4. 04

    Review before release

    Inspect the merge request. Required reviews and human decisions determine what can proceed.

EXAMPLE WORKFLOWIllustration, not live telemetry
GITLAB / ISSUE

Fix the empty-state crash on the settings page

Include reproduction steps, expected behavior, and a regression test.

Scoped assignment
  1. 01Engineer →
  2. 02QA →
  3. 03Reviewer →
  4. 04Release

A result you can inspect.

A proposed fix, reproducible checks, and a reviewable merge request.

Handoffs depend on issue metadata, role access, and the configured gates.

03 DIVISION OF LABOR

Eight roles.
Clear responsibilities.

Select a role to see what it contributes. These are role descriptions, not live availability indicators.

Coordinate / ROLE 01

A clear assignment for the right specialist.

Triages issues, identifies risk, and routes scoped work. GitLab stays the durable work queue.

EXPECTED OUTPUTScope, acceptance criteria, and a role assignment

THE DESIGN, MADE VISIBLE

Coverage. Continuity. Control.

Configuration diagrams, not model scores or performance benchmarks.

01 / ROLE COVERAGE

Separate the work from the checks.

  • Coordinate1
  • Build3
  • Check3
  • Deliver1

Engineer, Platform, and Docs implement. QA, Reviewer, and Security provide separate checks.

02 / MODEL CHOICES

Fit the model to the work.

  1. 1
    Task fitCapability and context
  2. 2
    Provider termsData handling and eligibility
  3. 3
    Quotas & budgetsAccount-specific limits
  4. 4
    VerificationTest the exact route

Models and account limits change. Catalogue listings are not evidence of working access or a universal free entitlement.

03 / DEPLOYMENT CONTROL

Checks before changes.

  1. 01Static policy
  2. 02Validate
  3. 03Preflight
  4. 04Plan reviewOperator decision
  5. 05Authorized apply
  6. 06Verify

04 STRAIGHT ANSWERS

A few things worth knowing.

How does a role know what to do?

Work starts from a scoped GitLab issue, acceptance criteria, repository context, and an authorized assignment. Assignment alone does not prove runtime activation.

Can it merge or deploy without review?

Implementation and release are separate responsibilities. Credentials, branch protection, approvals, and explicit authority enforce the boundary; prompts alone do not.

Are these diagrams live activity?

No. They illustrate the design, not current availability, benchmark results, or a guaranteed completion time.

Is workforce available to purchase?

No. Workforce is internal-only. No new orders or payments are accepted, and no external distribution is offered.

Joseph Gettings Jr, donniedice

BUILT BY AN OPERATOR

donniedice.

Joseph Gettings Jr builds workforce for his own technical workflows. DiceMatrix is the infrastructure it runs within, not the project’s author.

Back to the portfolio →