The code already exists.
December will not wait.
December is approaching. Dispatch works, but delivery windows are missing. Import the system, find what could block the change, and carry the next release all the way to production.
Before adding delivery windows, open the code.
Import codebase
Linked repository
north-pole / dispatchnorth-pole / dispatch
main
Start analysisChoose Import codebase when creating the project; link a repository before analysis.
src/routes/search.tssrc/dispatch/capacity.tssrc/db/schema.tsinfra/service.tfFrom repository evidence to a reviewable backlog
- Code-derived documents
- Repository scans
- Policy assessment
- Initial backlog
Each proposed repair cites its recorded findings or policy gaps.
Before adding delivery windows, the team needs to know how Dispatch works today. The import reveals the existing routes, data and infrastructure the change must preserve.
The import continues when you leave the page. Review its interpretation and proposed work before choosing what enters the queue.
Find the route the new feature must preserve.
Project documents
Dispatch capacity
Each route has a fixed capacity. The current application assigns a route, but has no delivery-window booking.Each route has a fixed capacity. The current application assigns a route, but has no delivery-window booking.
src/dispatch/capacity.ts · lines 12–28The source-linked document shows how dispatch works today. The team records what delivery windows must preserve before extending the system.
The record stays derived from code; it is refreshed rather than edited by hand.
The team chooses to fix this risk first.
Maintaining
SQL query constructed from request text
opengrep · insecure code
src/routes/search.ts:24Fix this findingUse parameterized database queries.
src/routes/search.ts:24 · a17c042
Maintaining finds request text used as SQL and cites the published parameterized-query control. The team prioritizes this existing risk before releasing delivery windows.
This is a cited breach of one control. Controls without recorded evidence are not declared compliant.
The evidence becomes a queue you control.
Initiatives
Initial backlog · generated from import evidence
- FIX-07Parameterize dispatch searchPlanning
Source: SEC-04 · src/routes/search.ts:24
- INIT-08Book a delivery window
Business request · WINDOW-01
No initiatives
No initiatives
Build on its own by default · enabledMerge review · a person must approve
The initial backlog cites the findings and policy gaps it addresses. The team queues the search repair first, then the delivery-window feature. One initiative runs at a time.
Import generates the backlog. Your priorities decide what enters the queue; this example builds automatically and requires human merge review.
Fix the search query.
Remediation initiative
Parameterize dispatch search
- 1Planning
- 2Building
- 3Your review
db.query(`SELECT * FROM routes WHERE name = '${query}'`);db.query('SELECT * FROM routes WHERE name = $1', [query]);db.query('SELECT * FROM routes WHERE name = $1', [query]);Search treats input as data
PR #42 · Reviewed and mergedThe queued repair is planned against the repository, then built under the project’s autonomy setting. The reviewer checks the parameterized query before merging it.
Build on its own is enabled here. Required reviews and branch protections still govern the merge.
The finding has to disappear from the scan.
Finding verification
src/routes/search.ts:24Same rule. Same file. Pattern no longer detected.
This finding resolved. Other controls still need their own evidence.
A failed scanner keeps its earlier findings open.The finding stays open until the scan checks the corrected file. When the same rule no longer detects it, the finding resolves.
A passing build alone does not resolve a finding. A failed scan does not count as clean.
Now the queue reaches the business change.
Initiative · next in the queue
Book a delivery window
Let dispatchers reserve an available delivery window for a route. A full window must reject the booking.Let dispatchers reserve an available delivery window for a route. A full window must reject the booking.
- Reserve an available window.
- Reject a full window without changing capacity.
- Keep existing route identifiers and assignments.
WINDOW-01 · Never overbook a window
The search repair has merged. The next queued initiative can proceed: reserve delivery windows without overbooking, keeping the existing route identifiers and database.
The queue advances after the previous pull request merges. Its deployment and verification records remain separate.
A reservation needs one transaction.
Initiative plan
Illustrative implementation plan
Keep PostgreSQL. Reserve capacity in the same transaction as the booking.
Existing code + project instructions + acceptance criteria
Two requests for the final space: only one succeeds.
The plan connects a small schema addition, an atomic reservation, the API, the interface and boundary tests.
This is the example app’s architecture, not a Taiga API.
A full window must stay full.
Run
BEGIN;
UPDATE delivery_windows
SET reserved = reserved + 1
WHERE id = $1 AND reserved < capacity
RETURNING id;
-- Insert booking only if a row returned.
COMMIT;BEGIN;
UPDATE delivery_windows
SET reserved = reserved + 1
WHERE id = $1 AND reserved < capacity
RETURNING id;
-- Insert booking only if a row returned.
COMMIT;Full window accepted a booking
Full window rejected · capacity unchanged
Final space: one request accepted · one rejected
Illustrative code and test results
The first implementation accepts a booking it should reject. The run corrects capacity handling and repeats the tests, including two competing requests for the final space.
These are illustrative run results, not an executed customer delivery.
The change is ready to inspect.
Pull request
Add delivery-window booking
- Plan and acceptance criteria
- Code and migration
- Tests and recorded run
Branch protections and configured review rules still apply.
The pull request brings the change, migration and verification record together. The reviewer checks the work before merge.
Repository protections and selected automation settings govern the real merge.
One change, through to production.
Deployments
What is running in each environment, and the deployments that got it there.
c39e264main · GitHub Actionsc39e264main · GitHub Actionsc39e264ProductionSucceededc39e264DevelopmentSucceededYour configured pipeline deploys. Taiga brings its reported versions, environments and history into the project.
The configured pipeline takes the merged change through development checks and production approval. Taiga shows the connected deployment record.
Production is an outcome in this fictional story. The app below runs only in your browser.
The release becomes a system you can watch.
Monitoring
The team uses runtime evidence to choose what to improve next.
Illustrative records and measurements. No live systems are connected.
Availability checks and browser signals keep the running environment visible. The team can inspect the release and use the evidence to decide what comes next.
Illustrative monitoring. URL checks require a configured public URL; browser signals require the installed beacon. New samples are still learning a baseline.
The next dispatch has a window.
The existing route is still here. Now a dispatcher can reserve a delivery window without overbooking it.
NP-042 · Rovaniemi
240 parcels · existing route
Delivery window
Browser-only demo. Fictional data; no backend, deployment, real identity or persistent storage.
North Pole Dispatch is an illustrative project. Repository files, findings, policies, commits and run results are examples, not customer evidence.
After release
Configured URL checks, browser signals from the installed beacon and repository sweeps inform the next decision. A deployment record alone does not establish application health.