AI Collaboration Capstone: One Change, Both Tracks

Return to the AI Collaboration Course #

Deliver PROP-042 twice, through GitHub-first and through GitHub with Confluence/Jira. You contribute, separate owners review, and authorized publishers apply the change. Use isolated synthetic sandboxes after preceding lessons. The capstone tests the complete procedure, including rejection, recovery, and independent handoff, rather than assistant prose quality.

Key Takeaways #

• One shared change compares both authority models.
• Negative tests matter as much as successful delivery.
• Evidence packages support independent review.
• Lab completion does not authorize production rollout.

Before You Begin #

Prerequisites: preceding course modules , approved sandbox access, and separate reviewers. Estimated time: three to four hours plus review. Difficulty: advanced.

Required artifacts: charter, map, policy, adapters, baseline, manifest, fixed proposal, owner reviews, ledger, recovery record, and handoff. Missing plan-dependent permissions block completion instead of becoming assumed passes.

Establish Two Baselines #

1. Create isolated runs named GitHub-first and Mixed. Keep revisions and reviews separate.
2. Restore seven-day baseline through each track’s approved procedure and capture resulting revisions.
3. Verify denial controls with contributor and excluded-user accounts.
4. Capture current context and confirm adapter/policy agreement.
5. Declare the scope: thirty-day synthetic export retention, excluding real data, backups, and legal holds.

PROP-042 is a correlation label, not reusable approval. Each run needs its own frozen revision and source evidence. Include run IDs in reports.

Deliver GitHub-First #

Open the Issue and candidate PR using the GitHub lessons. Change requirement, configuration, proposal, and runbook together. Capture the protected base, run trusted checks, and obtain product and operations reviews at the final commit.

Run: GitHub-first
Change: synthetic retention 7 -> 30 days
Requirement: REQ-17 revision 2
Configuration: retention_days 30
Runbook: Retention days: 30
Proposal: base revision 1, from 7, to 30
Manifest: protected pre-change source hashes
Review: product and operations at final proposal revision
Publication: merged commit and read-back
Limit: no running deletion service exercised

Fill actual references from the sandbox. The outline is expected mapping, not completed evidence. The maintainer merges only after review, then independently reads main. Close the Issue after linking the final records.

Deliver the Mixed Track #

Read Confluence versions and freeze the Jira proposal. Obtain both owner reviews. Publish the requirement with delivery pending, merge configuration, publish the runbook, and read all systems back before Done.

Record each publication with page version, commit, or transition evidence. Repository requirement copies remain snapshots. The local checker does not establish current Confluence authority.

Choose a workflow by ownership needs. GitHub-first reduces cross-system coordination. The mixed track preserves workplace homes and adds publication/access checks.

Run the Failure Matrix #

Cross-system conflict belongs to Mixed. In GitHub-first, test an Issue description conflicting with the approved file. Run other applicable cases in both tracks. A local validator failure does not replace live permission evidence.

Keep expected and observed outcomes separate. For each case record run ID, actor role, initial revisions, attempted action, expectation, observation, resulting revisions, and reviewer decision. Redact credentials and account identifiers from shared reports.

Assess Completion #

Pass requires observed evidence for every applicable row and independent acceptance. Reviewers inspect permissions, source freshness, role review, partial publication, and handoff reconstruction as well as consistency logs.

Fail immediately on unauthorized publication, denied text reaching the model, or silent overwrite of a changed base. Keep work Blocked until corrected controls pass a repeat test. Do not average these failures into a favorable score.

Measure completed/blocked cases, rejected stale proposals, denied writes, recoveries, and reviewer time. Proposed outcomes remain expected until observed. The supplied ten unit tests cover consistency, not live tenant security.

Plan the Two Runs #

Do not reuse an approval across tracks. The requested value is the same, but the source homes, captured revisions, permissions, and publishing sequence differ. Give each run its own evidence directory and review packet.

capstone-evidence/
  github-first/
    charter-and-map
    captured-sources
    fixed-proposal
    role-reviews
    consistency-results
    permission-results
    publication-readback
    recovery-and-handoff
  mixed/
    same evidence categories, independently captured

These names are an organization example, not supplied archive files. Store actual evidence privately in the approved sandbox. Shared course submissions should use role labels and redacted references, while reviewers retain access to native records.

Assign a test observer before running failures. The contributor performs the attempted action. The observer records initial state, outcome, and resulting state. A reviewer later determines whether the evidence supports the claim. Disclose role overlap instead of implying independent acceptance.

Run Failures in Isolation #

Reset to a verified reviewed state between cases. Injecting source drift, access revocation, and a runbook mismatch together obscures which control rejected the proposal. One failure per run gives the reviewer a traceable reason for the result.

1. Capture the initial state: source revisions, configuration, delivery state, and actor role.
2. Apply one synthetic injection: change one relevant condition through an authorized test route.
3. Attempt the bounded action: validation, read, publication, or handoff.
4. Record the observation: actual output and resulting source state.
5. Repair through review: preserve failure evidence before restoring controls.
6. Repeat the positive case: confirm the corrected workflow still delivers permitted work.

A planned failure is still a failure observation. Do not relabel unauthorized publication as a successful test merely because you intended to probe it. The test succeeded at exposing a defect, but the publication boundary failed and requires repair.

Interpret a Mixed Result #

Illustrative evidence package: local consistency passes, product and operations review the fixed package, requirement publication succeeds, and runbook edit access is denied. Configuration has not yet merged. Jira remains Blocked.

Expected reasoning: keep the run incomplete, verify current sources, and request the appropriate owner decision. Do not finish by weakening permissions or describing the snapshot check as live publication evidence.

Review With an Independent Reader #

Ask the reviewer to reconstruct events, not merely read your conclusion. They should locate the approved baseline, fixed proposal, owner decisions, resulting revisions, failed attempts, repair, and remaining gaps without your narration.

Reviewer questions:
Which source governs retention intent in this track?
Which exact package did each owner review?
Did any source change after review?
What was published, and what remains pending?
Which denied action was observed under which role?
Did protected text reach an excluded user's context?
Which repair was reviewed and read back?
Does the fresh handoff reconstruct current state independently?

Score each requirement separately. Use Supported, Failed, Blocked, or Not run with an evidence reference. Consistency, approval, permissions, recovery, and handoff are separate requirements. A collection of green local tests does not offset a failed live publication boundary.

Write a Bounded Decision #

A useful closing decision names the next pilot, not an unrestricted rollout. For example, choose another synthetic export setting with the same roles and direct lookup route, while leaving real data and automated publication out of scope.

Completion check: both run packages survive independent reconstruction, applicable failure cases have observed evidence, and unresolved controls remain visible. If only the GitHub track is complete, report partial course completion rather than assuming the mixed track would behave the same way.

Troubleshooting and Backout #

Only happy-path evidence: rerun denial and interruption tests. Overlapping roles: disclose and repeat with separate users. Missing plan controls: stop and obtain an approved sandbox.

Backout: restore baseline through reviewed PRs and Confluence edits, revoke temporary integrations, archive Jira evidence, and perform owner-approved synthetic cleanup after evidence retention. Preserve recovery history.

Create the Rollout Decision #

Decision: another synthetic pilot, blocked, or rejected
Evidence: both run packages and failure matrix
Unenforced requirements: procedural controls listed explicitly
Provider review: input scope and retention handling
Owner coverage: product, operations, policy, repository, delivery
Production gaps: runtime tests, secrets, deployment, access review
Next action: one bounded follow-up with accountable role
Review date: assigned by pilot owners

Expected reasoning: synthetic success supports another bounded pilot. Production requires separate approval for real data, deployment, provider handling, and runtime behavior. A successful assistant answer is not deployment authorization.

Primary References #

• Repository controls: Protected branches .
• Workplace access: Confluence permissions .
• Delivery controls: Jira permission schemes .

Next Steps #

Return to the course hub to review missing controls. Compare your implementation with the framework article before selecting another pilot.