Change requests and decisions

The scope clauseCopy Anchor Link

The validation sheet of the cahier (p. 2) ends with this clause:

« Toute fonctionnalité non décrite ou non validée dans le présent cahier des charges fera l’objet d’une analyse complémentaire, d’un chiffrage séparé ou d’une planification dans une version ultérieure. »

Any feature that is not described or not validated in the cahier is analysed separately, priced separately, or planned for a later version. The team applies it literally, and to both sides: nothing is added silently, and nothing described is dropped silently.

What is in scope is the cahier as signed on the validation sheet, plus what HOCO validates afterwards: the PRD and SRS baseline at the cadrage workshop (PRJ-03), each surface's designs after its feedback round, and the decisions in the register. The V1/V2 split follows cahier §14.1/§14.2 and the scope page. Team decisions already in the plan — the reseller web (RWA-01) and the product decisions of the team (for example after-sales and returns in V1) — are part of the baseline presented to HOCO at the cadrage workshop, not change requests.

What is a change requestCopy Anchor Link

Grey-zone rule: a "clarification" whose answer adds more than half a day to a task's estimate is a change request.

How a request becomes a decisionCopy Anchor Link

Change-request templateCopy Anchor Link

# CR-007 — <short title>
Requested by: <name, role at HOCO> · Received: YYYY-MM-DD via <review | call | WhatsApp | e-mail>
Status: Open | Analysed | Decided | Applied | Declined · Owner: Anis

## Request
What HOCO asks for, in their words (French quote).
## Reason
The business need behind it.
## Impact on scope
Requirements added or changed (ids, V1/V2), screens, operations, apps (BO, RA, RW, DA, API).
## Impact on plan
Tasks added or changed, effort per person (optimized days), milestones moved — computed by the scheduler.
## Impact on cost
Priced separately: <amount or "to quote">.
## Risks
## Options
A. Add now · B. Swap with <V1 item> · C. Plan in V2 · D. Decline
## Recommendation
## Decision
Option <X>, decided by <name> on YYYY-MM-DD — reference: e-mail "<subject>". Register: D-xx.

Updating the planCopy Anchor Link

The plan is changed like code, and only through tasks.json:

git switch -c docs/cr-007-plan
# edit apps/docs/content/plan/tasks.json: optimized/effort, deps, release, team, or a new task
pnpm --filter @hoco/docs schedule      # prints the new calendar, warns on unknown dependencies
pnpm docs:generate                     # regenerates the team-task pages
pnpm --filter @hoco/docs check-mdx     # every page still compiles
git add apps/docs/content/plan/tasks.json apps/docs/content/docs/team-tasks
git commit -m "docs(plan): apply CR-007 — export invoices to Excel"

• The plan change is its own commit, so the plan's history reads cleanly (planning method).
• A new task takes the next free id of its prefix (SRV, DSH, MRA…); ids of removed tasks are never reused.
• Dates are never edited, and an estimate is never shrunk to keep a date. The levers are real ones: scope, sequence, owner, capacity (If dates slip).
• Imad and Akram review a plan PR that touches their lanes. Once merged, the docs deploy publishes the new timeline, and Anis notes the change on the Progress page.

The decision registerCopy Anchor Link

The register is the open decisions page. A decision not written there did not happen.

Rules:

• Anyone opens an entry (through Anis) as soon as a question blocks or will block a task.
• Every open decision has a default. When its needed-by task starts without an answer, the default applies, HOCO is told in writing, and changing it later is a change request.
• Decisions are taken in writing only; the entry quotes its source.
• Nothing is deleted. A new entry supersedes an old one and links back.
• The register is read at the Sunday planning (what is due this week) and at each client review (what HOCO must decide).
• Technical decisions of the team are ADRs on the architecture page; they are not HOCO's to sign.

Sign-off momentsCopy Anchor Link

The PV is signed when the priority scenarios of cahier §12 pass, the blocking defects are fixed, and the open Majors are listed as reserves with their fix versions (acceptance rule, acceptance scenarios). Signed documents are kept as PDFs in the project's shared folder and referenced from the register entry of the moment they close.

3-month frame: design → development → deployment — deadline 17 Jan 2027.