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.
它做什么
写一份交接文档,总结这次对话里发生的事,让新的代理(或新的会话)不必从头开始就能继续工作。
工作方式
- 输入 /handoff,后面可以写上下一个会话要做什么,文档会据此调整重点。
- 文档保存在操作系统的临时目录,而不是你的项目里。
- 已经记录在规格、计划、工单、提交或 diff 里的内容不会重复写,只给出路径或链接。
- 末尾加一节"建议使用的 skill",列出下一个代理应该加载的 skill,并对密钥、密码和个人信息做脱敏。
适合场景
想换个地方继续的长会话,或把工作交给另一个代理。
需要了解
我们试用时,它记下了会议上的决定、需要改的具体行号、测试缺口和待定问题。
纯指令文件:没有脚本、不联网。 它是需要你手动输入的命令(/handoff),代理不会自己启动。它会在操作系统的临时目录(不是你的项目目录)写入一个 Markdown 文件,不运行脚本。文件内容来自你们的对话,尽管 Skill 要求代理脱敏密钥、密码和个人信息,分享之前仍请自己检查是否有敏感内容。 压缩包里另有原仓库的 MIT 协议文件 LICENSE 和 agents/openai.yaml(供 Codex 使用的显示名)。