Skip to content

v0.5.0

Choose a tag to compare

@JHSeo-git JHSeo-git released this 02 Sep 00:46
· 24 commits to main since this release
  • Upstream sync: bump pin 5020dbb → 64903f9 (upstream v0.5.0). One minor release with a real architectural addition and two behavior reversals worth reading carefully. Out of scope: provider and transport plumbing (#743 Bedrock maxTokens, #744 forced Copilot streaming, #416 OpenRouter debug-fetch concurrency), connector runtime fixes (#414), the Windows fingerprint stat-identity fix (#781 — this port has no fingerprint), and upstream's own wiki updates (#747/#757/#759/#764/#770/#773/#785) plus the version-packages chore (#754).

  • Durable per-page resumability arrives upstream, and this port reads it without writing it (#720). Upstream added a committed openwiki/.page-manifest.json ledger recording, per page, the commit and source fingerprint it was verified against plus which producer completed it — so a run that dies on page nine of twelve can publish the eight good pages and the next run starts from them instead of from scratch. The port cannot write an entry, and the reason is structural rather than a shortcut: buildManifestEntry only accepts a page whose .claims sidecar exists and carries a verification event matching the page's current bytes, and this port keeps no sidecar and stamps no verified (Step 5's long-standing [omitted]). Fabricating an entry would assert a machine verification that never happened. What the port does do is read the part that needs no sidecar — each entry's gitHead — so skills/openwiki/SKILL.md Step 1 now builds real per-page update baselines when a native or CI run left a manifest behind, which is exactly the payoff of merging a partially-failed CI PR. Two fail-safes are recorded so a later sync does not "fix" them: a native run following a port run finds the coverage unverifiable and re-reviews those pages (stale-but-ignored, the safe direction), and upstream's hasCompleteBaselineCoverage no-op gate is deliberately not ported, because a presence test in a port that never records entries would wedge every future update into a full run.

  • The planner's update context is now per-page windows, not one flat changed-path list (#720) — references/prompt-planner.md. Upstream replaced "Changed repository paths" with "Committed per-page update windows" plus the rule that gives it teeth: a page already advanced by a merged partial update must not be regenerated for changes at or before its baseline. The port renders real cohorts from the manifest when one exists and otherwise degrades to the single baseline it can prove (.last-update.json's gitHead, or full review when none was recorded) — which is what it did before, now stated as one window instead of a list. A cohort with an empty changed-path set is upstream's fast-forward case reached by a different road: the port cannot advance a ledger it does not write, but "nothing visible moved since this baseline" falls out of the window itself.

  • Claims reconciliation became sparse upstream, and this port says plainly how little of that is live here (#769). Upstream stopped round-tripping a page's whole Claim set through the model: submit_page now takes only {confirmedClaimIds, claims, retractedClaimIds}, an omitted issue-free Claim is retained rather than retracted (the inverse of the old rule), the complete set moved behind a new on-demand inspect_claims tool, and the page prompt renders a Claim count plus only the stale/unresolved ones. CLAIMS_RECONCILIATION_GUIDANCE and the submit_page paragraph are ported verbatim so the next sync stays line-mappable — but with no sidecar this port has no persisted Claim ids at all, so the two id fields and inspect_claims have nothing to name and every submission is "all added". references/prompt-page.md now opens by saying so, and keeps the id-free half that does transfer: don't re-derive a page's whole grounding on a focused update (read its sources on demand — that is this port's inspect_claims), give every resource Step 1 flagged an explicit recheck decision rather than leaving it cited-but-unchecked, and respect the net floor that replaced the old min(1) payload rule — a completed page must retain or establish at least one material Claim. Also ported: one decision per id, and the deliberate asymmetry that a retraction of an unknown id is tolerated (delete-like, for retry safety) while confirm and update stay strict.

  • An unrecognizable language request now stops the run instead of quietly producing an English wiki (#761) — both wiki skills' Step 1. Upstream reversed itself here: warning and falling back to English persisted the wrong language in run state, and since resume refuses to change a started run's language, the user could not fix a typo without deleting OpenWiki's own state files. The port rejects at the entry, before any write, with upstream's new message. One [adapted] difference that matters: upstream validates a --language flag, so its advice is "use a code rather than a language name" — this port's input is prose, so mapping "Korean" to ko is the skill's job, and it stops only when no real language is identifiable at all.

  • Partial progress is now a publishable CI result, not a failure to hide (#720) — references/automation.md and skills/openwiki/SKILL.md Step 6. Upstream's workflow gained continue-on-error on the OpenWiki step, a rm -f -- openwiki/.run.json cleanup, a PR opened even on failure with the outcome in the body ("merge it to make that progress the baseline for the next scheduled run"), and a final step that re-raises the failure so the job stays red. All three recipes here follow suit; GitLab and Bitbucket capture the exit code and re-raise it after pushing, since neither has continue-on-error. Step 6 now states the port's equivalent of upstream's manifest baseline: the status: "interrupted" metadata with a rewound gitHead that it already wrote for a skipped page is the "this much is done" record, so a partial run's output should be reported as committable rather than offered up for tidying away. One honest caveat recorded in both places: claude -p exits 0 when the skill merely skips a page, so .last-update.json's status is the partial-run signal, not the CI job status.

  • Smaller ports. cursor joins claude-code / codex / opencode in both wiki skills' provenance-actor list (#748). The provenance pass gains an explicit rule that a wiki may legitimately carry different generated.by actors across pages and you must never normalize another host's actor to yours — upstream made this concrete in #720 by tracking the completing producer per page and passing producerActorsByPage into the finalizer, now that a durable run can be resumed by a different host (which also means resume no longer rejects a mismatched producer). A rollback or deletion that reports the file was already absent is success, not an error, and is now attributed (#767 — upstream's backends spell that outcome two ways). Restating an already-fixed plan is no longer an error while replacing it still is (#789), so prompt-planner.md states the rule that survives for a port with no tool: the page set is fixed once the queue starts. And openwiki/.page-manifest.json joins the never-hand-edit list, the no-op worktree-clean ignore list (upstream widened isUpdateMetadataStatusLine), and — deliberately not — the content-snapshot exclusions, since it is committed wiki output and a change to it is a real content change. openwiki-ask learns to read its per-page gitHead as a sharper freshness signal than the whole-wiki .last-update.json.