An application workstream from request to delivery
This illustrative workstream extends the support-triage application. It shows how to organize a real change once the application and environment have been onboarded. The issue names and evidence below are a proposed acceptance plan, not a recorded production run.
Objective
When our helpdesk retries a support submission, keep one queue record and preserve its original urgency. Ship the change to our managed application and verify it with a duplicate submission.
Redgold continues to operate the route, executor, datasets and deployment. The helpdesk is an external integration: its retry behavior and granted connection are inputs to the application contract.
1. Agree the contract and record the work
Create a workstream for reliable support intake. Its root records the managed application, environment, intended result and integration boundary. Split it into reviewable issues:
| Issue | Acceptance | Depends on |
|---|---|---|
| Define duplicate semantics | Decide how request id, changed body and urgency interact | Customer decision |
| Implement duplicate handling | Focused tests prove one logical queue entry and preserved urgency | Agreed contract |
| Prepare acceptance requests | First submit, identical retry and changed-body retry have explicit expected results | Agreed contract |
| Deliver and verify | Reviewed revision is deployed and the acceptance requests match | Implementation and fixtures |
The workstream can hold these issues while proposed. Human approval and the managed scheduler's eligibility rules govern automatic dispatch.
2. Resolve a blocked decision
The implementing agent discovers that the helpdesk may resend the same id with an edited body. Overwriting the original could change priority; ignoring the edit could hide new information. It records that question on the issue instead of silently choosing product behavior.
For this example, the customer chooses: identical retries return the existing record, and a changed body under the same id is rejected. The decision becomes part of acceptance. The agent can now continue against an explicit contract.
3. Run independent work and integrate
One agent owns the schema/transform change. Another can prepare acceptance fixtures from the agreed behavior without editing the implementation files. The coordinating run brings the results into one reviewed change and checks that the fixtures actually exercise the implementation.
If the implementation session restarts, recover its workspace diff, issue comments and last test result before continuing. The new session should not create a second implementation because the original terminal disappeared.
4. Review and release through the managed path
Review the behavior change, compatibility with stored records and focused test output. Redgold validates and publishes the approved artifacts and reconciles the deployment for the managed environment. An approved diff, passing check and live revision are separate pieces of evidence.
The customer does not need to provision a queue database, run executor pods or edit deployment manifests to complete this workflow. The onboarding agreement identifies the application's delivery/status surface and approval policy.
5. Verify the result and close the loop
Run the application's committed acceptance requests with an authorized test record. Record the actual result next to these expectations:
| Action | Expected result for the agreed contract |
|---|---|
| Submit an urgent request with a new id | One accepted high-priority queue record |
| Repeat the identical request | Existing logical record; no duplicate queue entry |
| Reuse the id with changed body | Documented rejection; original record preserved |
| Read the test record in its authorized scope | Original urgency and content remain |
Attach the revision, required check results, managed deployment evidence and sanitized smoke results to the delivery issue. If the running revision differs, recover deployment before diagnosing the transform. Close the workstream only when its objective is met and any residual work is explicitly accounted for.
The same organization supports an external app repository. In that case, replace the managed publication stage with the connected repository's own release process and identify who verifies its hosting. Continue with managed deployment for the Redgold application path.