Scenario 04: Develop a bounded feature

Use this scenario after the product outcome, task scope, acceptance criteria, and evidence lanes have been accepted. It helps a developer investigate integration points and comparable code before implementing the smallest test-backed change. Planning, code review, security review, QA, and release closure remain separate delivery stages.

Required task context

Begin mutation after the task carrier identifies:

• the user outcome and exclusions;
• testable acceptance_criteria;
• the current revision and bounded file_paths;
• relevant source_refs, tests, and interface contracts;
• the expected review, AppSec, QA, documentation, traceability, and release lanes;
• rollback or recovery expectations for risky behavior.

If these inputs are missing, continue planning and investigation without editing production code.

Typed investigation request

The supported role-bound surface uses RoleBoundScenarioInvocationRequest and invoke_role_bound_scenario_request:

from src.digital_employees.runtime.scenarios import (
    RoleBoundScenarioInvocationRequest,
    invoke_role_bound_scenario_request,
)

request = RoleBoundScenarioInvocationRequest(
    query="Find integration points and regression risks for the accepted feature slice.",
    employee_id="codegraph_developer",
    scenario_id="scenario_04",
    event_type="implementation_start",
    context={
        "project_key": "codegraph",
        "namespace": "default",
        "task_id": "<task-id>",
        "acceptance_criteria": ["<criterion>"],
        "file_paths": ["src/example.py", "tests/test_example.py"],
        "source_refs": ["openspec/changes/<change-id>/specs/<capability>/spec.md"],
    },
)

result = invoke_role_bound_scenario_request(request)

The contract requires non-empty project_key, namespace, and task_id. Missing scope fails closed with role_bound_scenario_contract_missing. The request returns investigation context and role-bound evidence; file edits use a separate implementation workflow for the paths listed in file_paths.

Tests-first implementation loop

1. Verify the task revision and inspect the smallest relevant source, tests, and callers.
2. Map the intended behavior to one or more acceptance criteria.
3. Add a focused test that reproduces the missing behavior or defect and observe RED for the intended reason.
4. Make the smallest implementation or configuration change that produces GREEN.
5. Run the focused test, nearby regression tests, and lint/type checks for the touched surface.
6. Review changed symbols, callers, persistence and API contracts, authorization boundaries, and public documentation impact.
7. Record revision-bound commands, results, and evidence references for each acceptance criterion.

Keep the patch within the accepted scope when the graph exposes adjacent debt. Record unrelated findings separately.

What a useful investigation returns

The result should distinguish:

• confirmed integration points from ranked candidates;
• current callers and data or control-flow boundaries;
• similar implementations that are safe to reuse;
• files that are in scope from files that are merely affected;
• known unknowns, freshness limitations, and permission gaps;
• focused tests and lane reviews still required.

Graph centrality or similarity is a navigation signal. The architecture owner confirms the proposed change in current source and tests.

Stop conditions

Return to the task owner when the accepted behavior is ambiguous, a new public surface is required, the revision changed concurrently, the necessary path is outside the task scope, or the change would cross an unapproved trust boundary. Repair the carrier, acceptance evidence, and lane verdicts only through their accountable workflows.

Maintained source contracts

• Public typed exports: src/digital_employees/runtime/scenarios/__init__.py
• Scenario routing and required scope: src/digital_employees/runtime/scenarios/role_bound_scenario_invoker.py
• Developer employee policy: src/digital_employees/runtime/scenarios/employee_scenario_invocation.py

For request details, see Programmatic Guide. For a new repository, complete Onboarding before selecting an implementation slice.