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 と入力します。続けて次のセッションで何をするかを書くと、文書はそれに合わせて作られます。
- 文書はプロジェクトではなく、OS の一時フォルダに保存されます。
- 仕様、計画、チケット、コミット、diff にすでにある内容は繰り返さず、パスやリンクで示します。
- 次のエージェントが読み込むべき skill を挙げる「推奨 skill」の節を付け、キー、パスワード、個人情報は伏せます。
向いている場面
別の場所で続けたい長いセッション、別のエージェントへの作業の引き渡し。
知っておきたいこと
私たちの試用では、会議で決まった内容、変更すべき具体的な行、テストの不足、未解決の質問が記録されました。
指示だけのファイルで、スクリプトはなく、ネットワーク接続も行いません。 手動で入力するコマンド(/handoff)で、エージェントが自分で起動することはありません。OS の一時フォルダ(プロジェクトの外)に Markdown ファイルを 1 つ書き込み、スクリプトは実行しません。内容は会話から作られます。Skill はキー、パスワード、個人情報を伏せるよう指示していますが、共有する前に機密情報が含まれていないか確認してください。 パッケージには元リポジトリの MIT ライセンス(LICENSE)と agents/openai.yaml(Codex 用の表示名)も含まれます。