Northstar · Internal tools
Name changed for confidentialityTurning routine bug reports into reviewable fixes.
I designed and built an internal workspace that investigates suitable Jira tickets, prepares code changes and returns them to engineers with verification context.
Across six product repositories, even a small bug required someone to reconstruct context before making a change. I connected ticket intake, investigation and review so the team could delegate that preparation while retaining control of what shipped.
View larger ↗At a glance
- My responsibility
- Workflow and interface design, engineering, integrations and exception handling.
- Scope
- Six repositories, from ticket intake through investigation and implementation to review.
- Existing tools
- Jira for priorities, GitHub for code review and Slack for notifications.
- Team-reported outcome
- Bugs and hotfixes resolved and shipped to production 8× faster. From report to production, compared with the team’s previous workflow.
Keep one backlog and one review process
I used a Jira label to select work for automation, keeping priority with the engineering lead. The workspace collected ticket descriptions and attachments, screened the content and checked whether there was enough information to proceed.
The refinement form helped the person reporting a problem assemble its description, screenshots and sprint context. Missing information could return with an explanation before an investigation consumed more resources.
View flowchart ↗
View larger ↗Make progress useful to the person responsible
I brought the current stage, repository, branch and attempt count into one ticket view. Activity logs explained the investigation; model usage exposed its resource consumption.
Try the workflow
Mission control
Selected work, moving forward.
Ticket queue
Sample activityRuns return a proposed change, verification evidence and anything that still needs attention.
Refine a ticket
Give the investigation a useful starting point.
Report form shows old validation on reopen
Expected: Reopening the modal starts with no validation message. An empty submission still shows the required-field error.
Scope: Trace the form lifecycle, reset stale validation state and verify both behaviours.
Report form shows old validation on reopen
Trace the modal lifecycle and preserve validation on submission.
- ✓Read ticket
- ✓Triage
- 03Investigate
- 04Plan
- 05Implement
- 06Verify
Finding the root cause
Sample activityChecking the close and cancel handlers before deciding where the reset belongs.
Clear reproduction steps and expected behaviour.
Read the admin conventions and dependency notes.
Inspecting form state and close handlers.
View execution details
READ memory/repos/admin.md READ src/reports/ReportModal.tsx FIND hasTriedSubmit survives modal close NEXT check cancel and dismiss handlers
A focused change, ready for a second look.
Implementation complete. Engineering review is the next step.
Handoff summary
PR #128 · sampleReset the submission flag when the report modal closes. Both cancel and dismiss use the same reset path.
WHY THIS FIXThe previous submission flag persisted between openings. The change addresses the state lifecycle and keeps the existing required-field validation.
Verification evidence
Close and reopenNo stale validation message
Submit an empty formRequired-field error appears
Build and type checkCompleted without errors
Proposed change · ReportModal.tsx
const closeReport = () => { - setOpen(false); + setHasTriedSubmit(false); + setOpen(false); }; + // Both close and cancel use closeReport. + // Required-field checks stay on submit.
Inspect the change or send feedback for another attempt.
Six repositories. One workspace.
Conventions and dependencies travel with the ticket.
Admin
Staff tools and reporting
Context availableClient
Customer-facing application
Context availableResume
Document services
Context availableJobs
Job search and matching
Context availableWorker
Background processing
Context availableCommon
Shared types and utilities
Context availableA ticket through the workflow
One ticket on the original dashboard concerned a report-generation modal: old validation messages remained when it was closed and reopened. The ticket requested resetting the attempted-submission state on both Close and Cancel.
The planner investigates those handlers and records a proposed change. The implementer carries that context into the code. A separate verification run then attempts the behaviour the reviewer needs checked:
- An incomplete submission still shows validation.
- Closing and reopening the modal clears stale messages.
- Cancel follows the same reset behaviour.
View larger ↗Recover work without losing the investigation
A runtime crash records the exact error and can trigger a bounded repair attempt. Reviewer feedback can also return work for revision, reusing the existing branch and investigation context.
I added retry limits, timeouts and repository queues to bound resource use and conflicting edits. Persisted state and journals support recovery after an interruption.
View flowchart ↗Used by the team, with review assigned internally
The team reported that bugs and hotfixes were resolved and shipped to production 8× faster than with the previous workflow. The improvement covered the time from a reported issue to a fix in production, rather than just the time to generate a code change.
The workspace handled investigation and implementation so routine fixes could move forward without pulling engineers away from planned development. Engineers retained review and approval: the assigned engineer assessed the proposed change and verification evidence, requested corrections where needed, and decided whether to approve it for release.
| Person | What the workspace provides | What stays with them |
|---|---|---|
| Product or support | A refinement entry point and an explanation when essential context is missing. | Describe the problem, expected behaviour and supporting evidence. |
| Engineering lead | Ticket progress, run activity, usage and intervention controls. | Select suitable work, set priority and decide when to intervene. |
| Assigned engineer | A proposed code change, investigation context and verification outcome. | Assess correctness, check gaps, request revisions and approve the merge. |
What I owned
I designed and built the intake, operator dashboard, integrations, agent orchestration and recovery controls around the team’s existing repositories and tools. Northstar’s engineers retained code review and approval. My responsibility was to make the workflow between those points usable, connected and recoverable.