Parallax Release 2 - Priority Critical Path (lean plan)¶
A trimmed companion to the full roadmap. Contains only the four client-priority items and their absolute (hard) dependencies - the minimum needed to deliver each priority. Related and nice-to-have items are intentionally excluded (see the full roadmap for those).
1. What this plan is¶
The client set this delivery sequence: S7 -> T2 -> R2 -> R18.
This document strips each priority down to its critical path - the priority item plus only what it cannot ship without. It is the leanest version of Release 2's committed scope.
Definition of "absolute dependency": an item the priority literally cannot be built or shipped without. Robustness fixes, usability extras, and consumer features are not included here even when valuable - they live in the full roadmap.
| # | Priority | Lead item | Absolute dependency | Excluded (in full roadmap) |
|---|---|---|---|---|
| 1 | Strategies update (Import/Export) | S7 | (none) | S9, S15, S5, S8 |
| 2 | Templates updates by source | T2 | T1 | T12, T8 |
| 3 | Interactive Strategy Report | R2 | R1 | R12, R13, T10, S13* |
| 4 | Summary Report | R18 | (none) | R16, T11, R17, R3, R14 |
* S13 (faster strategy calc) is only required if the ISR's "results in ~1 second" target is contractual. The ISR itself functions without it. Treated as conditional - confirm with the client.
Lean effort total: ~56 developer-days (vs ~112 for the full roadmap).
2. Critical path at a glance¶
flowchart LR
subgraph P1["Priority 1"]
S7["S7 Strategy import/export"]
end
subgraph P2["Priority 2"]
T1["T1 Source-based templates"] --> T2["T2 Master template + inheritance"]
end
subgraph P3["Priority 3"]
R1["R1 Column formatting"] --> R2["R2 Interactive Strategy Report"]
S13["S13 Faster calc (only if <1s SLA)"]:::cond -.-> R2
end
subgraph P4["Priority 4"]
R18["R18 Summary redesign + home page"]
end
S7 --> T1
T2 --> R1
R2 --> R18
classDef cond stroke-dasharray: 5 5,stroke:#888;
| Sprint | Items | Effort (dev-days) | ~Duration |
|---|---|---|---|
| 1 | S7 | 5 | ~1 week |
| 2 | T1, T2 | 18 | ~3.5 weeks |
| 3 | R1, R2 | 21 | ~4 weeks |
| 4 | R18 | 12 | ~2.5 weeks |
| Total | 56 | ~11 weeks |
(Conditional: add S13 = +7 days only if the sub-1-second ISR target is required.)
3. Sprint 1 - Strategy Import / Export (S7)¶
~5 developer-days. No hard dependency - builds on the existing, production-proven strategy-copy logic.
- Business problem: Moving many strategies between hotels or environments is manual and error-prone.
- User story: As a strategy manager, I want to import/export strategies in bulk with a validation report, so that I can move them safely and see problems up front.
- Solution approach: a reusable import/export pipeline; export produces a portable file; import validates each strategy (duplicate detection, error reporting) before saving and returns a clear pass/fail report.
- Exit criteria: a batch of strategies imports correctly; duplicates and errors are detected and listed in a report; export round-trips.
- Impacted areas: Strategies, Data Import/Export.
4. Sprint 2 - Templates by Source & Inheritance (T1 -> T2)¶
~18 developer-days. T1 is the absolute dependency of T2 (inheritance is built on source-based templates).
T1 - Source-based templates - Business problem: Templates are managed per hotel, so similar ones pile up and there's no way to see all templates for a given source. - User story: As an admin, I want templates labelled by data source so I can filter and manage by source. - Exit criteria: every template has a source; the templates screen can be filtered by source.
T2 - Master template + per-hotel inheritance - Business problem: Every hotel needs its own near-identical template, so one change must be repeated across many hotels. - User story: As a hotel ops user, I want one master template that each hotel tweaks only where it differs, so I maintain one master, not dozens of copies. - Exit criteria: a hotel template can be linked to a master; changing the master updates non-overridden hotels; overrides win; inherited vs overridden is clearly marked; reports are no slower.
Solution approach: templates gain a source label and an optional link to a master. Values resolve down the chain - master first, then the hotel's override - with safeguards against circular references; screens mark inherited vs overridden.
flowchart TD
Master["Master template (by source)"] -- "inherits" --> Hotel["Hotel template (overrides only)"]
Hotel --> Resolver{"Value resolver<br/>(hotel override -> else master)<br/>+ loop protection"}
Resolver --> Reports["Reports & calculations"]
- Impacted areas: Templates, Attributes, Reports.
5. Sprint 3 - Interactive Strategy Report (R1 -> R2)¶
~21 developer-days. R1 is the absolute dependency of R2 (the report can't render formatted figures without it). The ISR's consumers (Excel round-trip, per-day publish, price overrides) are excluded here - they're in the full roadmap.
R1 - Column formatting - Business problem: Report columns don't show currency/percentage/number symbols or control decimals. - User story: As a report user, I want to format each column as currency/percentage/number with chosen decimals. - Exit criteria: a column can be formatted with symbol and decimals; formatting renders correctly.
R2 - Interactive Strategy Report - Business problem: No single interactive place to review/adjust pricing per day; seasons, events and overrides are handled separately and don't update live. - User story: As a revenue manager, I want a live calendar-and-grid report where I adjust season/event/override settings per day and see results immediately. - Exit criteria: per-day dropdowns drive a live recalculation; the calendar and grid never desync; mandatory columns can't be removed; the advanced filter works.
Solution approach: a synced calendar + grid; each day exposes season/event/override dropdowns; changing a day triggers a fast per-day recalculation path (separate from the full refresh).
flowchart TD
Cal["Calendar"] <--> Grid["Data grid"]
Grid --> Drop["Per-day dropdowns"]
Drop --> Recalc{"Per-day live recalc"}
Recalc --> Calc["Strategy calculation"]
Calc --> Grid
- Impacted areas: Reports, Strategies.
- Conditional: if a sub-1-second recalc is contractually required, add S13 (faster strategy calc, +7 days).
6. Sprint 4 - Summary Report Redesign & Home Page (R18)¶
~12 developer-days. No confirmed hard dependency - standalone redesign + landing page.
- Business problem: The Summary report needs a refresh, and after login users don't land on a useful overview.
- User story: As a user, I want a redesigned Summary report shown automatically as my home page after login.
- Solution approach: fully redesign the Summary report (new layout/render) and set it as the post-login landing page.
- Exit criteria: the Summary report is redesigned; after login users land on it by default; it renders correctly with real data and handles the empty/no-data case.
- Impacted areas: Reports, Authentication (post-login landing).
flowchart LR
Login["User logs in"] --> Landing{"Landing resolver"} --> Summary["Redesigned Summary report (home)"]
Open question: if the redesigned Summary is to be shipped as a shared company/hotel/user standard report, the underlying "standard report" capability must exist. If it isn't already in place, that capability becomes an absolute dependency and would need adding. Confirm with the client.
7. Notes¶
- Order follows the client sequence (S7 -> T2 -> R2 -> R18); the only hard dependencies (T1 before T2, R1 before R2) sit inside their own sprint.
- This is the minimum. The fuller, more usable delivery (robustness fixes, ISR Excel/audit/override
features, Summary inheritance and saved settings) is in
r2-client-priority-roadmap.md. - Two confirmations can change this lean scope: the ISR sub-1-second SLA (pulls in S13), and the Summary "standard report" capability (could add a dependency to R18).