refactoring.md

title	ramping sheet feature spec
priority	10

the scenarios need improvements

1

Then the coding heads should be as follows
    | Team | Release  | Initiative | Heads   |
    | Algo | CT\VB70A | 0          | 2;3;3;3 |
    | Algo | CT\VB80A | 0          | 2;3;4;4 |

header should be the months and then we need column for every month

like we do here

And the following ramping sheet
    | Team | Release  | HotFix | Stay Alive | Arch Budget | Availability Factor | Initiative | 2021-01-01 | 2021-02-01 | 2021-03-01 | 2021-04-01 |
    | Algo | CT\VB70A | 2      | 1          | 10%         | 0.65                | 0          | 2          | 3          | 3          | 3          |
    | Algo | CT\VB80A | 2      | 1          | 10%         | 0.65                | 0          | 2          | 3          | 4          | 4          |

2

why do we need additional step

Then the tech-debt budget for team 'Algo' in release 'CT\PI\PI09' should be '10%'

when we already have

Then the team capacities should be as follows
    | Team      | Release    | AvailabilityFactor | CorridorHotFix | CorridorStayAlive | TechDebtBudget |
    | Emergency | CT\PI\PI21 | 0.65               | 0.75           | 2                 | 10%            |

3

this step

Then the total coding heads for team 'Algo' should be '4'

makes no sense because it does the computation in the step

do we even need it when we have a step verifying the heads per month?

4

we dont need this step

"the teams with non-empty capacities should"

rather use this

" And the coding heads should be as follows "

and maybe rephrase as a more general team capacity verification step

---

Implementation Plan — ramping sheet feature spec quality (Risk: LOW — auto-approved)

Specs-only refactoring of system/Foundation/BackLook.PlanningSheet.Specs/PlanningSheet/ReadingRamping.feature and its step bindings in system/Foundation/BackLook.PlanningSheet.Specs/Steps.fs. No production change. All steps Verifier-owned.

1. Feature Intent and Scope

• Goal: improve the ramping-sheet scenarios' readability and remove redundant / compute-in-step assertions, per the 4 asks above.
• Business value: specs become the single, clear source of behavior; fewer overlapping step phrases; coding-heads expectations are read the same shape as the input ramping sheet (per-month columns).
• In scope: ReadingRamping.feature scenario tables + the four affected [<Then>] step bindings in Steps.fs.
• Out of scope: production code; any change to ramping computation/aggregation behavior; the relative tech-debt budget ... within '<tol>' step (kept — table form cannot express tolerance); other .feature files.

2. Acceptance Behavior (Gherkin)

Per-month coding-heads shape (ask 1), exhaustive over (Team, Release, Initiative) rows:

Then the coding heads should be as follows
    | Team | Release  | Initiative | 2021-01-01 | 2021-02-01 | 2021-03-01 | 2021-04-01 |
    | Algo | CT\VB70A | 0          | 2          | 3          | 3          | 3          |
    | Algo | CT\VB80A | 0          | 2          | 3          | 4          | 4          |

Binding assertions:

• The step asserts the complete set of actual (Team, Release, Initiative) head-series equals the table exactly — a stray release (e.g. doc-only Defects) or team (e.g. past-version CoVa) fails.
• Each date column is a month; empty cell = that month absent for the row. Month order independent.

3. Impact Map

• Owning context: BackLook.PlanningSheet.Specs (Foundation specs). No other context affected.
• Contract changes: none (no production).
• No-change areas: production system/Foundation/BackLook.Domain ramping/capacity code; the the relative tech-debt budget ... within ... step; the team capacities should be as follows step's existing columns.

4. Assumptions and Open Questions

• Resolved (user): the new coding heads should be as follows step is exhaustive over (Team, Release, Initiative) rows, so it cleanly replaces both total coding heads ... (ask 3) and teams with non-empty capacities ... (ask 4) exclusion checks.
• Assumption: months for each coding-heads table are derivable from each scenario's input ramping sheet; the Verifier rewrites each table from the corresponding the following ramping sheet input.

5. Implementation Steps

• S1 (Verifier) — Ask 1: rewrite the coding heads should be as follows binding (Steps.fs:237) to read date/month columns instead of a Heads semicolon column, and assert the exhaustive set of (Team, Release, Initiative) head-series. Rewrite the 4 existing usages (feature lines ~43, ~412, ~438, ~465) to per-month columns. Gate green.
• S2 (Verifier) — Ask 3: replace each the total coding heads for team ... should be ... usage (feature lines ~279, ~294, ~311, ~322) with an exhaustive per-month coding heads should be as follows table that proves the doc-only / past release is excluded; remove the now-unused the total coding heads for team '(.*)' should be '(.*)' binding (Steps.fs:281).
• S3 (Verifier) — Ask 4: replace each the teams with non-empty capacities should be ... usage (feature lines ~337, ~352, ~369, ~386, ~398) with an exhaustive coding heads should be as follows table (proves excluded team absent); remove the the teams with non-empty capacities should be '(.*)' binding (Steps.fs:297).
• S4 (Verifier) — Ask 2: replace the standalone the tech-debt budget for team ... should be ... usages (feature lines ~18, ~29, ~117, ~133, and the two ~PI21 release scenarios) with single-row the team capacities should be as follows tables carrying a TechDebtBudget column; refactor the standalone exact-match assertion (Steps.fs:192) into a private helper still called by the table dispatcher (Steps.fs:417), and remove the public [<Then>] standalone binding. Keep the relative tech-debt budget ... within ... step untouched. Delete this issue file in the S4 completion commit.

6. Verification Plan

• Per step: bake specs Foundation (or scoped dotnet test on BackLook.PlanningSheet.Specs) must stay green; each step independently reviewable/revertible.
• After S4: full BackLook.PlanningSheet.Specs green + arch-fitness 0 errors.

7. Risks and Rollback

• Risk: exhaustive coding-heads could surface a latent actual-vs-expected mismatch in a rewritten scenario. Mitigation: rewrite each table from its own input ramping sheet; if a real mismatch appears, STOP and report (do not weaken the step). Rollback: revert the slice commit (specs only, no production impact).