ritsu v0.40.0

ritsu 0.40.0

Added

• sakai's E208 holds a rule's implements as it holds a workflow's: the service a rule implements must be under open host service of a published language of the rule's own context. Rules that implement the services of one contract are published as the contract: published language <the contract's package> with proto "<contract>", and the services the rules implement under open host service; the rules need only be owned. Where rules published one by one meet in one block (E004) or in one package (E006), the notes show this form. A context that publishes one such rule as a block of its own (rulec "<rule>", in the contract's package) still passes, with the service under that block's open host service.
• use rule … connect to a rule that implements a contract's service lands on the published language that lists the contract, and passes when the service is an open host service there. It was E202.
• sakai doc lists rules among what implements an open host service, with the service each one implements.
• rulec gen names the .proto an earlier gen wrote for a rule before the rule implemented a contract's service, when it is still in the output directory at another path than the contract's copy, and says it can be deleted. It deletes nothing, and the exit code is what it was. --check names it too, and --format json lists it under a new key, left. Only a file whose first line is rulec's head (// Code generated by rulec …) is named.
• ritsu check --format json gives what each file's own language says of it: each item of files ends with check, what the language's check --format json writes of that file, without its file, root and diagnostics, in the language's own shape. A kaname module's has its summary and the effect of each function; a book's, its report; a spec's, its claims; a date file's, a gate's, a map's and a module's requirements' (the same on each of its .req files), their ok and summary. A rule's, a .proto's and that of a context that is no map are null, and a flow's is {}.
• ritsu check --format json lists each border it checked: borders keeps held, failed and undecided, and adds records, one for each border, as many as the three add up to. A record says which check it is (precondition, rule_date_input, range_from_koyomi, transfer_amount, transfer_refusals, hold_expiry, koyomi_date_input, secret_destination, operation_guard or workflow_permission), what it is about, its two sides at and to, each with its tool, file and line (and its dependency in a module), its result, and the code of the diagnostic ritsu gave (null when it holds). The records come in the order of those words, then by the file and the line of at. A check keeps its word, and a new one is added at the end.
• dandori's date and timestamp take a range where a number does: in the workflow's inputs and outputs, a record's fields, and a task's arguments and results. The ends are days, >=2026-01-01 <=2027-12-31, or one of them alone; a time's ends are days in UTC, or at the offset written after them (offset +09:00). A value is checked where it comes in, as a number is: an input outside its range fails the run with Dandori.BadInput, a result outside it with Dandori.BadResponse. Every platform compares the text: a date's ten characters with the range's first and last days, and a time's first nineteen characters (to the second) with the range's first second and the first second after the range, so 23:59:59.5Z is inside the second it is in.
• now range >=2026-01-01 <=2027-12-31 under workflow says the period the workflow runs in (an offset can follow). A run that starts outside it calls nothing and fails with Dandori.OutOfPeriod, as a run with a bad input does, and on failure does not run. Each statement that reads now checks the clock first and reads that moment; outside the period, the run goes to on failure as it does for a task's error that nothing handles (it is not retried, and a task's on does not take it), and fails where there is no on failure. now in on failure and on cancel is not held to the period, so that the cleanup runs whatever the clock says.
• dandori's checks hold dates, times and now to their ranges. The check of ranges (E014, W104) holds them to the ranges they are given to; in a workflow that says its period, now is a moment of that period, and the day of a koyomi date is the days koyomi counts for it. E015 holds a child flow's ranges of dates and times to the ranges the task gives its arguments. The check of a case left open (W101, E020) counts the check before a statement that reads now as a place the run can go to on failure from.
• dandori scenarios tries the ranges and the period: each input held to a range of dates or times just outside the range and at its ends (a time's last second with .5 after it), a run that starts just outside the period, and a run whose clock leaves the period after it starts. A scenario's now can be two moments, [start, later]; the runners of the seven platforms and ritsu run read both.
• dandori doc says the period at the head of the picture, Dandori.OutOfPeriod among the ends, and which lines' now can send the run to on failure.
• ritsu check decides the day a workflow gives over the range it comes from: the day given to a koyomi date's input (E205, W205), to a rule's date input (E202, W202), or to a rule input whose range is range from koyomi (E201, W201), when it comes from a date with a range, a time with a range, or now in the period. A time and now are read as days at the offset of the dates file's calendar, and a range with an open end can be outside. A relation between two dates with ranges (check_in <= check_out) is decided as one between numbers is.
• The records of those three checks in ritsu check --format json (koyomi_date_input, rule_date_input, and precondition for range from koyomi) have five more keys after code: given, takes, from (every place the day can come from, by its kind: day, range, moment, now, unknown or output), example and why.
• dandori's invoice example says the period it runs in, and ritsu check on it is all pass with 6 warnings, 8 borders checked and 6 undecided: the two W205 on its now are gone.

Fixed

• One statement reads one moment, however many times it says now, on every platform. Temporal (TypeScript, Python and Go) read the clock in the code each try of a call runs, so a call that was retried passed a later now on each try; the clock is read once, before the call. pydantic-graph read the clock for each now in a node; it is read once, at the head of the node. Argo evaluated now() in each expression; a template that reads the clock comes before each statement that reads now, and wait until and timeout until work their seconds out from one reading.
• The reference interpreter, run as Argo, gives a child workflow template's failure an empty cause, as Argo does.
• dandori doc says Dandori.BadInput and Dandori.BadResponse are an input and a result that do not fit the declared type or range.

Changed

• The rulec skill's SKILL.md keeps the steps of every change, and the steps for one occasion (in CI, rulec verify, rulec diff, rulec doc) move to more-of-the-loop.md, which SKILL.md points to. ritsu skills install writes the new file with the others.
• kaname names the checks across the languages by the words ritsu check gives them: precondition, rule_date_input, transfer_amount and koyomi_date_input, in places[].check of kaname check --format json, in checks[].check of kaname api, and in the sentences of a page of kaname doc for a place that waits for ritsu's answer (transfer_refusals for the reasons a transfer can be refused with). They were the marks of ritsu's design, X2, X3, X4 and X6.
• The Japanese of rulec gen's stop where a contract's copy would land on the .proto generated from a rule, and of the fixes of E076 and E310, calls the file gen copies a copy (コピー), as the rest of ritsu does; it used the word 写す.

On the site

• The top page's part on where the languages meet shows the JSON of a border's record, run from a reproduction, and the words of the ten checks.
• rulec's Generate says that gen names the .proto a rule left behind when it took a contract.
• dandori's Write a workflow and Dates and books show the ranges of dates and times and the period a workflow runs in, What it checks how they are checked, and Build for a platform how each platform reads the clock.
• The top page's list of the checks across the languages has the day a workflow gives a koyomi date from a range of dates or times, or from the period.

The Japanese pages say the same.

A home page in Simplified Chinese, at /zh/, introduces ritsu on one page and leaves the rest to the English pages. The repository has the same introduction as README.zh.md, and the READMEs and the site's language switch link to it.

Changes that can make a run that used to pass fail

• sakai check gives E208 for a rule that implements a service its context does not publish: the contract's .proto is in no published language of the context, or the service is not under that block's open host service. A rule published as rulec "<rule>" with no open host service gives E208 too; before, only a workflow that called it failed (E207).
• rulec gen --format json has one more key, left, always present. A reader that refuses keys it does not know sees a new one.
• ritsu check --format json has two more keys, always present: check on each item of files, and records in borders. A reader that refuses keys it does not know sees new ones.
• kaname check --format json and kaname api write check with a word in place of X2, X3, X4 or X6 (above). A reader that matched the marks sees the words.
• The Japanese texts of E076 and E310 that ritsu explain gives, and of rulec gen's stop above, are rewritten; a run that compares them with saved copies sees the difference.
• A flow that writes a range on a date or a time, or now range, is E001 for dandori 0.39.0.
• The generated code of a flow that reads now changes, whether it says a period or not. Temporal (TypeScript, Python and Go) reads the clock before a call that reads now (const dd_now_<site> = dd.now(); and the like). The clock is the workflow's and issues no command, so recorded histories replay as they did; the worker's build ID changes, and Worker Deployment Versioning takes it as a new build. A call that is retried passes the first try's now on every try. pydantic-graph reads the clock once at the head of a node. On Argo, a template that reads the clock comes before each statement that reads now, four more nodes each in E040's reckoning, so a flow near Argo's limit can come to E040. Step Functions and Lambda durable functions do not change.
• E003 for a range on a type that takes none, and E001 for a line under workflow, say more than they did; a check that matches their text sees the new text.
• The pages dandori doc writes for a flow that can end with Dandori.BadInput or Dandori.BadResponse change with those descriptions.

ritsu 0.40.0（日本語）

足したこと

• sakai の E208 は、ワークフローの implements と同じく、規則の implements も確かめます。 規則が実装するサービスは、その規則を持つコンテキストの公表された言語の open host service に書いてください。一つの契約のサービスを実装する規則は、契約を公表してください。published language <契約の package> の下に proto "<契約>" を書き、規則が実装するサービスを open host service に並べます。規則は owns に入っていれば足ります。規則を一つずつ公表しようとして、一つの塊（E004）か一つの package（E006）でぶつかると、注がこの形を案内します。規則を一つだけ、規則そのものを中身にした塊（rulec "<規則>"。package は契約のもの）で公表する形も、その open host service にサービスがあれば通ります。
• 契約のサービスを実装する規則を use rule … connect で呼ぶと、契約を並べた公表された言語に着き、そのサービスが公開ホストサービスなら通ります。 前は E202 でした。
• sakai doc は、公開ホストサービスを実装しているものに規則も並べ、規則が実装するサービスを書きます。
• 契約のサービスを実装する規則で、前の rulec gen が規則のために書いた .proto が、契約のコピーと違うパスに残っていれば、rulec gen はそのファイルを挙げ、消してかまわないと言います。 ファイルは消さず、終了コードも変えません。--check でも挙げ、--format json は新しいキー left に並べます。挙げるのは、一行目が rulec の頭の行（// Code generated by rulec …）のファイルだけです。
• ritsu check --format json は、ファイルごとに、そのファイルの言語が言うことを入れます。 files の各項目の最後に check が入ります。そのファイルの言語の check --format json がそのファイルについて書くものから、file・root・diagnostics を除いたもので、形はその言語のままです。kaname のモジュールなら summary と関数ごとの effect、帳簿なら report、geas の仕様なら claims、日付のファイル、ゲート、地図、モジュールの要件（そのモジュールのどの .req にも同じもの）なら ok と summary です。規則、.proto、地図でないコンテキストは null、フローは {} です。
• ritsu check --format json は、確かめた境目を一つずつ並べます。 borders は held・failed・undecided を残し、records に境目を一つずつ並べます。記録の数は三つの数の和と同じです。記録には、どの確かめか（precondition、rule_date_input、range_from_koyomi、transfer_amount、transfer_refusals、hold_expiry、koyomi_date_input、secret_destination、operation_guard、workflow_permission のどれか）、何についての境目か（about）、二つの側 at と to（どちらも tool・file・line。モジュールでは dependency も）、結果（result）、ritsu が出した診断のコード（code。成り立つときは null）が入ります。並びは語の順で、続いて at のファイルと行の順です。語は変えず、新しい確かめには新しい語を後ろに足します。
• dandori の date と timestamp に、数と同じ場所で range を書けます。 場所は、ワークフローの入力と出力、レコードのフィールド、タスクの引数と結果です。端は日で、>=2026-01-01 <=2027-12-31 のように書き、片方だけでもかまいません。時刻の範囲の端は UTC の日として読み、端のあとに offset +09:00 と書けば、そのオフセットの日として読みます。値は、数と同じく入ってくるところで確かめます。範囲の外の入力は Dandori.BadInput、範囲の外の結果は Dandori.BadResponse で実行が失敗します。比べ方はどのプラットフォームも文字列の比べです。日付は 10 文字を範囲の最初の日と最後の日と比べ、時刻は先頭の 19 文字（秒まで）を範囲の最初の秒と、範囲のすぐあとの最初の秒と比べます。23:59:59.5Z は、その秒の中の時刻として範囲に入ります。
• workflow の下に now range >=2026-01-01 <=2027-12-31 と書くと、ワークフローが動く期間になります（offset も書けます）。 期間の外で走り始めた実行は、何も呼ばずに Dandori.OutOfPeriod で失敗します。範囲の外の入力と同じ扱いで、on failure は走りません。now を読む文は、その前に時計を確かめ、確かめた時刻を読みます。期間の外なら、処理されなかったタスクのエラーと同じく on failure に入ります（リトライせず、タスクの on は受けません）。on failure が無ければ、ワークフローが失敗します。on failure と on cancel の中の now は、時計がいつを指しても後始末が走るよう、期間で確かめません。
• dandori の検査は、日付と時刻と now を範囲で確かめます。 範囲の検査（E014、W104）は、日付と時刻と now を、渡す先の範囲で確かめます。期間を書いたワークフローの now はその期間の時刻で、koyomi の日付の日は koyomi が数えた日として読みます。E015 は、子のフローの日付と時刻の範囲も、タスクの引数の範囲と比べます。案件が開いたままになる検査（W101、E020）は、now を読む文の前の確かめを、on failure に入りうるところとして数えます。
• dandori scenarios は、範囲と期間を試す実行を作ります。 日付と時刻の範囲を書いた入力ごとの、範囲のすぐ外と端（時刻は最後の秒に .5 を付けたもの）の実行と、期間のすぐ外で走り始める実行と、走り始めのあとで時計が期間を出る実行です。シナリオの now は、二つの時刻の並び [走り始め, それより後] でも書けます。七つのプラットフォームのランナーと ritsu run は、どちらの時刻も読みます。
• dandori doc は、図の頭に期間を、終わり方に Dandori.OutOfPeriod を書き、どの行の now が実行を on failure に入れうるかを言います。
• ritsu check は、ワークフローが渡す日を、その出どころの範囲で決めます。 koyomi の日付の入力（E205、W205）、規則の日付の入力（E202、W202）、範囲が range from koyomi の規則の入力（E201、W201）に渡す日です。出どころは、範囲を書いた日付と時刻、動く期間の中の now で、時刻と now は日付のファイルのカレンダーのオフセットで日に読みます。端の開いた範囲は、外れることがあると言います。範囲を書いた二つの日付の関係（check_in <= check_out）も、数と同じく決めます。
• ritsu check --format json の、この三つの確かめの記録（koyomi_date_input、rule_date_input、range from koyomi の precondition）には、code のあとに五つのキーが入ります。 given、takes、from（日が来うるところの並び。種類 kind は day・range・moment・now・unknown・output）、example、why です。
• dandori の請求の例は、ワークフローが動く期間を書きます。 ritsu check は警告 6 件で全部通り、境目は確かめた 8 か所・決められない 6 か所になります。now の W205 の 2 件が消えました。

直したこと

• 一つの文の now は、何度書いても、どのプラットフォームでも一つの時刻になりました。 Temporal（TypeScript、Python、Go）は、呼び出しの試しごとに走るコードの中で時計を読んでいたので、リトライした呼び出しは試しごとに後の now を渡していました。いまは呼び出しの前で一度だけ読みます。pydantic-graph は節点の中の now ごとに時計を読んでいました。いまは節点の頭で一度だけ読みます。Argo は式ごとに now() を評価していました。いまは now を読む文の前に時計を読むテンプレートを置き、wait until と timeout until の秒数も、一度読んだ時計から計算します。
• 参照インタプリタを Argo として流したとき、workflow template の子の失敗の理由を、Argo と同じく空にしました。
• dandori doc は、Dandori.BadInput と Dandori.BadResponse を「宣言した型か範囲に合わない入力」「宣言した型か範囲に合わない結果」と説明します。

変えたこと

• rulec のスキルの SKILL.md は、毎回の変更の手順を持ち、一度きりの段（CI、rulec verify、rulec diff、rulec doc）は more-of-the-loop.md に移りました。 SKILL.md がそのファイルを指します。ritsu skills install は、新しいファイルもほかと一緒に書きます。
• kaname は、言語をまたぐ確かめを ritsu check と同じ語で呼びます。 precondition、rule_date_input、transfer_amount、koyomi_date_input です。kaname check --format json の places[].check、kaname api の checks[].check、kaname doc のページで ritsu の答えを待つ場所の文が、この語を使います（振替の拒否の理由は transfer_refusals）。前は ritsu の設計の番号 X2・X3・X4・X6 でした。
• 規則から生成する .proto と同じパスに契約のコピーが来て rulec gen が止まるときの文と、E076 と E310 の直し方は、gen がコピーするファイルを「コピー」と言います。 ritsu のほかの文と同じ言い方です。前は「写す」と言っていました。

サイト

• トップの「言語が出会うところ」が、再現から走らせた境目の記録の JSON と、十の確かめの語を見せます。
• rulec の生成のページが、規則が契約に移ったあとに残った .proto を gen が挙げることを言います。
• dandori のワークフローを書くと日付と帳簿が、日付と時刻の範囲とワークフローが動く期間を見せ、何を検査するかが確かめ方を、プラットフォーム別のビルドがプラットフォームごとの時計の読み方を言います。
• トップの、言語をまたぐ確かめの一覧に、ワークフローが範囲と期間から koyomi の日付に渡す日が入りました。

英語のページも同じです。

簡体字のトップページ（/zh/）が、ritsu を一枚で紹介し、残りは英語のページに任せます。リポジトリにも同じ紹介を README.zh.md として置き、README とサイトの言語の切り替えからリンクします。

前は通っていた実行が落ちうる変更

• sakai check は、規則が実装するサービスを、規則のコンテキストが公表していないと E208 にします。 契約の .proto がコンテキストのどの公表された言語にも無いときと、サービスがその open host service に無いときです。rulec "<規則>" の形で open host service を書いていない地図も E208 になります。前は、規則を呼ぶワークフローだけが E207 で落ちていました。
• rulec gen --format json の答えに、いつも出るキー left が増えます。 知らないキーを受け付けない読み手には、新しいキーになります。
• ritsu check --format json の答えに、いつも出るキーが二つ増えます（files の各項目の check と、borders の records）。 知らないキーを受け付けない読み手には、新しいキーになります。
• kaname check --format json と kaname api の check は、X2・X3・X4・X6 の代わりに語を書きます（上）。番号で読んでいた読み手には、語が来ます。
• ritsu explain が言う E076 と E310 の日本語の文と、上の rulec gen が止まるときの日本語の文が書き直されました。 保存したものと比べる実行は、違いを見ます。
• 日付か時刻に範囲を書いたフローと、now range を書いたフローは、0.39.0 の dandori では E001 になります。
• now を読むフローの生成物が、期間を書かなくても変わります。 Temporal（TypeScript、Python、Go）は、now を読む呼び出しの前で時計を読みます（const dd_now_<場所> = dd.now(); など）。ワークフローの時計を読むだけでコマンドは出ないので、記録した履歴の再生は前のとおりです。ワーカーのビルドの ID は変わり、Worker Deployment Versioning では新しいビルドとして扱われます。リトライした呼び出しは、どの試しでも最初の試しの now を渡します。pydantic-graph は、節点の頭で一度だけ時計を読みます。Argo は、now を読む文ごとに、その前に時計を読むテンプレートが入り、E040 の見積もりが 4 ノードずつ増えます。Argo の上限に近いフローは E040 になることがあります。Step Functions と Lambda durable functions は変わりません。
• 範囲を書けない型に範囲を書いたときの E003 と、workflow の下の行の E001 の文が変わります。 文を突き合わせている検査には、新しい文になります。
• Dandori.BadInput か Dandori.BadResponse で終わりうるフローの dandori doc のページは、その説明が変わります。