AI Employees

​

Solution Architecture

This solution treats GitHub as the single source of truth that generates events. GitHub Actions handles event filtering and secure forwarding. The QoderWake API launches automated tasks to wake role-specific Wakers. Each Waker writes code, reviews, bugs, test evidence, and releases back to GitHub. Role behavior is governed long-term by a BIBLE; tasks run in isolated mode and maintain business state through GitHub markers.

​

Solution Advantages

​

Advantage 01: Event-Driven, Reduces Idle Polling and Race Conditions

Requirement status changes, PR revision updates, and code merges each have a well-defined event. Wakers are only woken when a meaningful change occurs, avoiding the idle polling overhead of scheduled scans and the race condition of "mid-scan state changing underneath."

​

Advantage 02: One Role, One Responsibility Boundary

Development, review, testing, and release use independent Wakers, independent BIBLEs, and independent API automated tasks. The Developer cannot approve their own work. The Reviewer does not modify code. The Tester does not fabricate deliverables. The Release Waker does not merge on the user's behalf.

​

Advantage 03: AI Output Written Back to the Source of Truth

Code, tests, comments, bugs, tags, and releases are all written back to GitHub. Chat history is useful for observing execution; GitHub is the fact that the next Waker can read and users can audit.

​

Advantage 04: Machine Execution and Human Decision-Making Operate at Different Layers

Wakers automatically handle analysis, coding, testing, and materials preparation, but code merges and official releases are still confirmed by users. AI improves execution efficiency; humans retain accountability for risk.

​

Advantage 05: Both Technical Idempotency and Business Idempotency

At the invocation layer, wakeSessionUniqueId prevents the same delivery from being executed twice. At the business layer, head SHA, merge SHA, and GitHub markers determine whether work has already been completed. Even if the platform retries or a duplicate event arrives, the Waker re-verifies and safely NOOPs.

​

Advantage 06: Credentials Exist Only Within the Secret Boundary

PATs and API addresses are stored only in GitHub Actions Secrets. The launcher masks inputs and uses encrypted writes. The Workflow injects credentials only at runtime, and error logs do not output response bodies or credentials.

​

Business Scenarios

​

Scenario 01: Release Waker Creates Iteration Boundaries and Release Packages

Automatically branches off an iteration after creation; prepares a release PR when tests pass; creates a tag and release after the user merges.

• Customer problem: Iteration boundaries and release materials often depend on manual preparation, which is prone to omissions and delays.
• Trigger: An iteration is created, or the Tester completes re-testing.
• Agent actions: Creates an iteration/* branch from main; aggregates requirements, bugs, PRs, and CI evidence to create a release PR; after the user merges, creates the tag, GitHub Release, and closes the Milestone.
• Deliverables: A dedicated iteration branch, release PR, tag, release, and closed Milestone.
• Completion definition: The iteration has clear boundaries; release materials are complete and auditable.
• Human Gate: User confirms merging the release PR.

​

Scenario 02: Developer Waker Delivers Engineering Work Starting from Requirement Facts

Woken by a requirement entering development or a bug being routed back, reads the facts, then delivers code, tests, and a code PR.

• Customer problem: AI only works when actively invoked; context has to be explained manually every time.
• Trigger: A requirement enters development, or a bug is routed back.
• Agent actions: Re-reads the requirement, acceptance criteria, comments, and existing PRs; creates a demo/feature/* or demo/bugfix/* branch from the iteration branch; adds tests, completes the minimal implementation, runs npm test and npm run lint; creates or updates the code PR with test evidence, linked issue, and a delivery marker.
• Deliverables: A code PR containing the implementation, tests, linked issue, and delivery marker.
• Completion definition: Code PR passes local tests and is linked to the requirement.
• Human Gate: User reviews the diff and merges the code PR.

​

Scenario 03: Reviewer Waker Performs Independent Review of a Specific Revision

Listens only to PR creation and new commit events; completes an independent review per head SHA and writes back the conclusion.

• Customer problem: Human review capacity is limited; if AI review conclusions stay in a chat window, they cannot be audited.
• Trigger: PR created, or a new commit is pushed to the source branch.
• Agent actions: Uses head SHA as the review unit; reads the complete diff, linked requirement, and CI; runs tests in an independent workspace; writes CHANGES_REQUESTED when a blocking issue exists; leaves [QW-REVIEW][sha][PASS] when the review passes.
• Deliverables: Review conclusion written back to the PR, covering tests, lint, CI, acceptance criteria, and diff scope.
• Completion definition: Reviewer PASS and CI passing; waiting for user to merge.
• Human Gate: User confirms merging the code PR.

​

Scenario 04: Tester Waker Automatically Routes Failed Acceptance Back to Development

Independently validates after code is merged into the iteration branch; creates a bug and automatically wakes the Developer to fix it when issues are found.

• Customer problem: When testing finds issues, notification often happens only in chat; evidence is incomplete and re-testing after a fix is hard to track.
• Trigger: Code is merged into the iteration branch.
• Agent actions: Independently validates; when a test fails, creates a Bug with reproduction steps, expected behavior, actual behavior, logs, and the parent requirement, then wakes the Developer to enter the fix flow; after re-testing passes, the Bug and Requirement move to a validated-complete state.
• Deliverables: A Bug Issue, or re-test passing status.
• Completion definition: The defect returns through the same Developer → Reviewer → Merge → Tester chain and is re-tested.
• Human Gate: User confirms merging the fixed code PR.

​

Reference Practice

​

Practice Name

QoderWake x GitHub: Event-Driven Development Collaboration Reference Practice

​

Practice Background

• Customer or industry: development teams that use GitHub as the source of truth.
• Original workflow: Status synchronization depends on manual reminders; context has to be copied repeatedly; AI-generated results stay in the chat window.
• Core problems: Events cannot automatically trigger AI execution; a single Agent lacks role separation; automated processes lack auditability.
• Pilot scope: An open-source reference implementation repository covering the Release, Developer, Reviewer, and Tester roles and a complete iteration.

​

Practice Design

• How events enter: GitHub generates events when Milestones, Issues, PRs, CI, and other states change — for example, a requirement entering development, a PR being created or updated, code being merged into the iteration branch, or re-testing passing.
• How the control layer routes: GitHub Actions listens to events, filters noise, prepares minimal context, and securely forwards events to the QoderWake API automated task. The PAT is injected from GitHub Secrets into the request header.
• How the Agent executes: The QoderWake API automated task runs in isolated mode, waking role-specific Wakers. Each Waker re-reads GitHub facts on every execution; the BIBLE constrains available tools, standard workflow, and prohibited actions.
• How results are written back: Wakers write code, review conclusions, bugs, test evidence, tags, and releases back to GitHub, forming facts that the next role can read and users can audit.
• How failures are routed back: When the Reviewer finds a blocking issue, it writes CHANGES_REQUESTED and returns the work to the Developer. When the Tester fails acceptance, it creates a Bug with reproduction evidence and automatically wakes the Developer to re-enter the fix flow.
• Where humans make decisions: Code PR merges and release PR merges are confirmed by users. The Release Waker does not merge on the user's behalf; it only prepares release materials.

​

Practice Workflow

​

Practice Outcomes

• Closed loop delivered: Complete handoff from requirement entering the iteration through version release, including development, review, testing, release, and bug routing.
• Validated capabilities: Event-driven waking, four-role responsibility separation, fact write-back to GitHub, human Merge gate, idempotent execution.
• Data and evidence: Example run screenshots and run records are available for reference; each restart generates a new unique Iteration and numbering.
• Future evolution: By replacing the event adapter layer and fact-reading tools, the solution can be migrated to an enterprise's own DevOps platform.

​

Recommended Product Bundle