The workflow at a glance
Identify the consolidated GitHub app, then use a non-private practice repository and known answers to check notification, task, PR and tests. An app-migration date is separate from task success. A PR does not establish that review, merging or deployment has occurred.
Identify the app before debugging an old entry point
GitHub’s October 23 announcement says the former GitHub notifications app becomes the consolidated entry. Existing notification users should update it; notification capabilities continue. A separate legacy GitHub app will be labeled GitHub (deprecated) and is scheduled for retirement on November 16, with migration to the consolidated app required.
Follow the consolidated app’s prompts to connect your own GitHub account and choose a repository. Installation and execution still depend on your organization and actual access. This article does not infer universal availability, subscription benefits or quotas from the announcement.
| Item | Evidence to record | Insufficient substitute |
|---|---|---|
| App identity | Which GitHub app is actually installed | A similar icon |
| Repository identity | Explicit owner/repository and branch | A channel nickname such as main repo |
| Task object | Specific issue link and acceptance criteria | An ambiguous notification |
| Result object | Corresponding PR and check results | A chat response or completion label alone |
Prepare a bug with independently checkable answers
The code and expected answers below are original editorial exercises, not an incident or a model’s output. The input contract is an array and the function returns its attachment count; it does not parse files or classify their contents. That narrow task lets you inspect identity, routing and code results separately.
The loop boundary skips the last element. An empty array happens to return the correct zero, so testing only that case hides the bug. Single-element and three-element cases expose the omission.
function countAttachments(items) {
let count = 0;
for (let i = 0; i < items.length - 1; i++) count++;
return count;
}
// Editorial reference cases:
// [] -> 0
// ['draft.pdf'] -> 1
// ['a.png', 'b.png', 'brief.pdf'] -> 3| Input | Correct count | Faulty result | What it checks |
|---|---|---|---|
| [] | 0 | 0 | Empty input cannot expose the omission |
| ['draft.pdf'] | 1 | 0 | Single-element boundary |
| ['a.png','b.png','brief.pdf'] | 3 | 2 | The skipped final element |
Turn the notification into an explicit task
In a practice repository you are authorized to use, record the issue with the function location, three inputs and expected answers. When its notification arrives in the intended Teams location, verify the issue and repository before submitting a task through the new app. These are reader-operated steps; we have not executed them in Teams.
The prompt deliberately limits scope. It does not treat notification text as a complete specification; the issue and fixed reference cases remain the acceptance basis. If the issue, code or repository is missing, supply it rather than inviting the agent to guess a target.
Investigate the linked practice issue in the selected repository.
The input contract of countAttachments is an array. Fix only the off-by-one counting error.
Reference results:
[] => 0
['draft.pdf'] => 1
['a.png', 'b.png', 'brief.pdf'] => 3
Add or update checks for these three cases. Explain which boundary was wrong.
Create a pull request for review. Do not merge or deploy.
If the issue, file or repository cannot be identified, stop and state the missing item.Inspect three chains after a PR appears
First inspect identity: notification, issue, repository, branch and PR must describe the same task. Next inspect scope: the change should repair counting without altering parsing, upload behavior or unrelated functions. Finally inspect results: execute all three reference cases and record failed or unrun checks honestly.
For this array contract, returning items.length directly is a simple reference solution; correcting the loop boundary is also possible. Results and scope matter more than imposing one style. Quietly changing the contract to count only PDFs would solve a different problem.
A PR exists, but acceptance still fails
Patch the boundary, demonstrate only empty input, and also start ignoring PNG attachments.
Verify all three reference cases and preserve counting of every supplied array element.
Record app migration separately from code repair
Before migration, retain the notification-subscription and target-repository records. Confirm that the same controlled issue arrives, remains identifiable and does not trigger duplicate work through the new entry, then handle the old entry under your normal administration process. This article changes no organizational installations or permissions.
For multiple repositories, use the Copilot investigation and repository-selection workflow. For scanning alerts rather than this practice issue, consult the agentic autofix PR-review boundaries. Do not merge the states of different entry points into one unsupported “everything works” label.
A trial record that supports a conclusion
- App and repository identity and the actual date are recorded.
- The practice issue and notification can be located from one another.
- The PR belongs to the task and its scope can be reviewed.
- All three inputs are checked; unrun items remain separate.
- Merging, deployment and production acceptance remain distinct later steps.
Capabilities this exercise has not tested
This is not a performance comparison. We have not called a model, installed a Teams app or created a real issue or PR. The code and answers establish a human reference; they do not prove access for an account or guarantee that a model will fix the bug.
If the entry is unavailable to your tenant or repository, record the actual message and verified conditions and retain an existing reliable route. Expanding permissions or automatically merging is not a substitute for a successful trial.
Common questions
Must existing GitHub notifications users install another app?
The announcement asks existing notification users to update to the latest consolidated app. Identify the installed application before confusing it with the separate legacy GitHub app scheduled for retirement.
Should I begin with a production incident?
This exercise starts with a small known specimen to establish the complete acceptance chain. A production problem needs its own authorization, materials and review process.
Do three passing cases authorize automatic deployment?
No. They verify the array-counting contract here. Full project checks, human review, merging and deployment remain separate steps.
