Here's how billing/due_dates.py behaves today:
- Business-day counting (
add_business_days, lines 4–12): It starts the day afterstartand counts only Mon–Fri. Holidays aren't considered, so a public holiday counts as a working day. The function has no country parameter. - Due-date calculation (
invoice_due_date, lines 15–21): It addsterms_daysbusiness days (default 10) to the issue date. Then it adds one calendar day whenissued.weekday() >= 4(lines 19–20). That condition covers Friday, Saturday and Sunday, not just Friday. A 10-day term always lands on a Friday for those issue days, so the extra day makes the due date a Saturday. For example, an invoice issued Fri 2026-10-02 is due Sat 2026-10-17. Removing the adjustment makes it Fri 2026-10-16. Anyone who has seen the current Saturday dates should know they will move one day earlier. - Where holiday support plugs in: The weekend check at line 10 (
if current.weekday() < 5) is the place to also skip holidays. To do that,add_business_daysandinvoice_due_datewould take acountryargument (or a set of holiday dates) and pass it down. A small loader would read the per-countryholidays.jsononce and cache it, starting with US and DE. Lines 18–20 come out at the same time, as planned.terms_days=10stays as it is.
I haven't changed any code. Two things to settle before November: what happens for a country that has no holidays.json (fail, or fall back to weekdays only), and whether the JSON files will include future years so dates stay correct around year-end.
Handoff document written by the skill:
Handoff: holiday support + removing the Friday adjustment in billing due dates
Date: 2026-10-04
Repo: <workdir> (branch main, clean, single commit fc8800b seed)
Next session's job: add public-holiday support and remove the Friday "+1 day" adjustment.
No code has been changed yet. The user said not to touch code in the previous session.
Decisions from today's planning meeting (not recorded anywhere else)
- The Friday "+1 day" adjustment in
invoice_due_dateis a bug. It will be removed. - Add public-holiday support by loading a
holidays.jsonfile per country. Start with US and DE. terms_dayskeeps its default of 10.- Finance wants this released before the November 2026 invoicing run.
Relevant files
billing/due_dates.py: the whole module, about 20 lines. Read it first.add_business_days(lines 4–12): skips weekends only. The check at line 10 (current.weekday() < 5) is where holiday skipping goes.invoice_due_date(lines 15–21): lines 18–20 hold the adjustment that is being removed.
tests/test_due_dates.py: only two tests. Neither covers the Friday adjustment or holidays.- No
holidays.jsonfiles and no loader exist yet. The location and format still need to be chosen.
Facts established in the previous session
- The adjustment condition is
issued.weekday() >= 4. It fires for invoices issued on Fri, Sat and Sun, not just Friday. - For those issue days, a 10-business-day term lands on a Friday. The +1 then makes the due date a Saturday. For example, an invoice issued Fri 2026-10-02 is currently due Sat 2026-10-17 and should be due Fri 2026-10-16. Removing the bug moves these dates one day earlier. This is worth mentioning in the PR or release notes for finance.
Suggested approach (not yet agreed with the user)
- Add a
countryparameter (or an injected set of holiday dates) toadd_business_daysandinvoice_due_date, and pass it down. - Add a small cached loader that reads per-country
holidays.jsonfiles, with US and DE first. - Delete lines 18–20 of
due_dates.pyand update the docstring or comment. - Tests to add: Fri/Sat/Sun issue dates without the +1, a due date pushed past a US holiday, a due date pushed past a DE holiday, and a check that the
terms_daysdefault stays 10.
Open questions for the user
- What should happen for a country with no
holidays.json: raise an error, or fall back to weekdays only? - Which years should the JSON files cover? Due dates near year-end need next year's holidays.
- Where should the JSON files live, and what schema should they use (for example, a list of ISO date strings)?
- Is
countryrequired, or optional with a default? Existing callers and tests currently pass no country.
Suggested skills
code-review: review the diff before committing or opening a PR.simplify: optional cleanup pass after the change is in.
Run the tests with pytest from the repo root. Commit and open a PR only if the user asks, and create a branch off main first.
I've written the handoff document for the next session at <system temp folder>/handoff-billing-holidays-2026-10-04.md. It's in the OS temp folder, not in the repo.
It covers:
- Meeting decisions: the four decisions from today's planning meeting, which aren't recorded anywhere else.
- Where the changes go: the line numbers in
billing/due_dates.pyfor removing the Friday adjustment and adding holiday skipping. - Current behaviour: the adjustment fires for invoices issued on Friday, Saturday and Sunday, and it produces Saturday due dates. Finance should be told those dates will move one day earlier.
- Test gaps:
tests/test_due_dates.pyhas only two tests, and neither covers the adjustment or holidays. - Open questions: what happens for a country with no holiday file, which years the files cover, where the files live and their format, and whether a country must always be given.
- Suggested skills:
code-reviewandsimplify.
I haven't changed any code, and the document contains no personal information or credentials.
Real run recorded with claude-code / claude-opus-5-5. This is a two-turn conversation: first the agent read the code and summarised it, then /handoff was entered. It is a command you type yourself, so the record shows a slash command rather than a Skill tool call. The handoff document is the agent's own text, written to the system temp folder, unmodified. The only change: the trial machine's temp-folder path was replaced with a generic placeholder.
Qué hace
Escribe un documento de traspaso que resume lo que ocurrió en esta conversación, para que un agente nuevo (o una sesión nueva) pueda continuar sin empezar desde cero.
Cómo funciona
- Escribes /handoff, opcionalmente seguido de aquello para lo que se usará la próxima sesión, y el documento se adapta a eso.
- Guarda el documento en la carpeta temporal de tu sistema operativo, no en tu proyecto.
- No repite nada que ya esté recogido en especificaciones, planes, issues, commits o diffs; en su lugar, apunta a ello mediante una ruta o un enlace.
- Añade una sección «skills sugeridas» que nombra las skills que el próximo agente debería cargar, y oculta claves, contraseñas y datos personales.
Ideal para
Sesiones largas que quieras continuar en otro lugar, o para pasar el trabajo a un agente distinto.
Conviene saber
En nuestra prueba, registró las decisiones de una reunión, las líneas exactas que había que cambiar, lagunas de pruebas y preguntas abiertas.
Archivos de solo instrucciones: sin scripts y sin acceso a la red. Es un comando que escribes (/handoff); el agente no lo inicia por su cuenta. Escribe un único archivo Markdown en la carpeta temporal de tu sistema operativo (no en tu proyecto) y no ejecuta ningún script. El archivo se genera a partir de tu conversación, así que revísalo por si contiene algo sensible antes de compartirlo, aunque la skill le indica al agente que oculte claves, contraseñas y datos personales. El paquete también contiene el archivo MIT LICENSE original y agents/openai.yaml (nombre visible para Codex).