Scope Basis and Assumptions
This plan delivers the complete ProEdits platform as specified in SRS v1.3, through to production deployment. All twelve SRS modules are built in full. There is no deferred phase, no reduced tier set and no partial add-on delivery.
What the platform does at go-live
The two non-negotiable rules
The SRS states only two requirements as firm rules rather than recommendations. Both constrain the architecture from the first week and are re-verified at every milestone gate.
Original files are never deleted
No delete route exists for an original. Deletion is blocked at the data-access layer and storage lifecycle rules exclude the originals prefix. An automated test asserts that project deletion, revision and add-on processing all leave originals intact. Built in Week 1, re-verified in Week 11.
“If an editor needs to manually fix windows, lighting, or other HDR problems, they may need access to the original exposures.”
One shared human queue
Exactly one service method creates an editing task. An architecture test fails the build if a task is created anywhere else. The method is idempotent, so no path can produce a duplicate task or silently drop one. Built in Week 4, before any consumer of it exists.
“Every AI failure or human request must enter your existing Traffic Management System.”
Assumptions
| # | Assumption | Consequence if it does not hold |
|---|
Delivery Model
Work is organised into module tracks. Each track corresponds to one functional area of the platform and runs across a defined set of weeks.
The programme runs at 20 hours of effort per week, for 12 weeks — 240 hours in total.
Those 20 hours are divided each week between the module tracks active in it: a week running four tracks gives each roughly five hours, a week running six divides the same 20 hours more finely. The weekly commitment never varies — what changes is how many fronts it is spread across. From Week 11 the whole 20 hours shifts to testing and deployment.
Feature freeze at Week 10
All feature development finishes at the end of Week 10. Weeks 11 and 12 contain no new functionality — only integration testing, cross-browser verification, performance measurement, a security pass, load testing, two defect rounds, staging soak, production build, go-live and handover.
A platform of this size cannot be tested meaningfully while it is still changing, and a deployment scheduled for the same week as the last feature is a deployment that slips.
Weekly working agreement
Per week: 16 h implementation, 3 h verification — tests written in the same week as the code they cover, never deferred — and 1 h coordination covering written status, cross-track integration points and open-issue chase.
Milestone gates
At the end of Weeks 4, 8 and 12: live demonstration against the exit-criteria checklist referenced to SRS identifiers; defect triage with blockers fixed inside the gate; the open-issue register updated; written sign-off before the next milestone begins.
Definition of Done — applies to every task without exception
| # | Condition |
|---|
Technology Stack
Exactly as confirmed. No substitutions.
| Part | Technology |
|---|
Three engines, one shared pipeline
The architecture the source flow document recommends and SRS §5.1 formalises. The three engines are separated in the codebase and in the deployment, not only conceptually, so that changing an AI model or vendor in one engine requires no change to the others, and so processing capacity grows independently of the web tier.
AI Pre-Processing
Python / OpenCV. Exposure detection, scene grouping, alignment, HDR merge, tone mapping, working-image render.
AI Add-On
Hosted AI APIs behind one internal adapter. Object removal, decluttering, lawn replacement, object manipulation, virtual staging.
Human Editing
NestJS workflow state in PostgreSQL with the staff interfaces. All human tiers, rejected AI results, and every revision.
Storage key convention
Fixed in Week 1 and used unchanged thereafter. Every saved result receives its own key; PostgreSQL records which original or earlier version it derives from. The bucket is private with no public access; every read is served through a time-limited presigned URL issued only after the API has authorised the request.
| File class | Key pattern | Written by |
|---|
Milestone Summary
Phase Breakdown by Module
All thirteen delivery tracks, mapped across the four milestones. Each milestone is three weeks and 60 hours. Every SRS module appears; nothing is deferred beyond the programme.
| # | Module | M1 · W1–3 | M2 · W4–6 | M3 · W7–9 | M4 · W10–12 | Weeks | Hours |
|---|
Gantt Chart
Each bar is a module track active across those weeks. The programme runs at 20 hours per week throughout, shared between whichever tracks are active. Milestone bands run across the top; hover a bar for its span and hours, and select a week header to highlight that column.
Timeline
| Week | Dates | MS | Active tracks | Hours | Cumul. | Key output |
|---|
Week-by-Week Tasks
Every task, grouped by module track. Every week's task hours sum to 20, and every track's hours sum to its total in the effort table.
Effort Distribution
By module track
| Module track | Share of 240 hours | Hours | Weeks active |
|---|
The two largest tracks are the add-on engine and the traffic-management layer. That weighting follows the source material: five independent generative effects each need their own input handling and quality validation, and the shared queue is the component every other module depends on — the one the SRS singles out as the most important part of the whole design.
By layer and by milestone
| Layer | Hours | Share |
|---|
| Milestone | Back | Front | Proc | Infra | T&D | Total |
|---|
Dependency Order and Critical Path
The SRS sets out a technical dependency order for the build in §9.5. This plan follows it exactly, running tracks in parallel only where the dependency allows.
| Seq | Item | Weeks | Why it sits here |
|---|
Week 4 is the hinge of the programme
It closes the ingestion chain — upload, grouping, merge, working image — and simultaneously stands up the two shared services that everything in Milestone 2 consumes: the single queue entry point and the credit ledger. A slip in Week 4 propagates directly to every track in Weeks 5 through 9.
Float — the only resequencing levers available
Most tracks run on the critical path. The items below carry float, listed in the order they should be used. Together they represent roughly 40 hours. Any use of them is agreed at a milestone gate and recorded, never taken silently.
| Item | Now | Move to | Cost of moving |
|---|
Cross-track integration points
Parallel tracks meet at defined points. Each is verified in the week it occurs rather than left to Week 11.
| Week | Integration point | Tracks meeting |
|---|
Acceptance Criteria and Traceability
Every functional requirement, non-functional requirement and business rule in SRS v1.3 mapped to the week that delivers it and the method that verifies it. Nothing is deferred beyond the programme.
| ID | Requirement | Week | Verified by |
|---|
Open Issues and Decision Deadlines
Every item in SRS Section 10. Each carries the Friday by which an answer is needed — the Friday before the week that consumes it — what it blocks, and the working default that will be built if the deadline passes.
| SRS § | Open issue | Needed by | Blocks | Working default if unanswered |
|---|
Risk Register
| # | Risk | Like. | Impact | Mitigation |
|---|
Explicitly Excluded
The following are outside this programme. Each is excluded either by the SRS itself or by the confirmed technology approach, not by a scope reduction made here. Everything else specified in SRS v1.3 is delivered inside these 12 weeks.
| Excluded | Reason |
|---|
Appendix A — Week × Module Hours Matrix
Each cell is that track's share of the week's 20 hours. Hover a row to trace it across the schedule.