Leaving the lead summary and the upgrade notes to be composed at publish
time put the writing at the worst possible moment — weeks after the changes,
with no review. Both belong in the CHANGELOG entry, which the release PR is
already editing.
The lead needed no code: text between the version heading and the first
group already flowed into the page. The Upgrade group did — CI appended its
own `## Upgrade`, so a CHANGELOG that carried upgrade notes produced two
headings. The group is now lifted out and the boilerplate wrapped around it,
pip line above, compare link below, matching every page since 1.1.3.
Publishing is now a read-through and a click.
Co-authored-by: zhanghui <zhanghui@shanda.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* ci: draft the GitHub Release page from the CHANGELOG on tag
release.yml only published to PyPI; creating the Release page was an
undocumented manual step, and v1.2.2 shipped to PyPI without one.
A second job, gated on a successful upload, now drafts the page: title
"EverOS X.Y.Z", body lifted from the matching CHANGELOG section with the
group headings demoted to h2, `--prerelease` for PEP 440 suffixed tags. It
stays a draft because the lead summary that opens every EverOS release page
is prose CI cannot write.
The job runs separately from the publish job so that one keeps `contents:
read` alongside its OIDC token. A stable tag with no CHANGELOG section fails
the job rather than publishing an empty page; pre-releases fall back to a
placeholder. Existing releases are detected through the list endpoint, since
the by-tag endpoint cannot see drafts (cli/cli#3037) and a re-run would 422 —
a stale draft is replaced, a published release left alone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* ci: prefill the Upgrade section on the drafted release page
Every EverOS release page since 1.1.3 closes with an Upgrade section — the
pip line, any migration notes, and a compare link to the previous tag. The
first draft dropped it, so a published page would have lost the one section
readers act on.
The pip line and the compare link are prefilled; the previous tag comes from
`git tag --sort=-v:refname`, which needs the full tag list, hence
fetch-depth: 0. Migration notes stay hand-written next to the lead summary,
since only a human knows whether a release needs them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(release): warn that API publishing drops the tag
Flipping `draft` through the API without `tag_name` rebinds the release to
the `untagged-<hash>` placeholder and creates a git tag by that name against
the default branch. Hit while publishing 1.2.2; the web UI button is
unaffected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: zhanghui <zhanghui@shanda.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* ci: enforce the file-size ceiling on pull requests
`check-added-large-files` only ran in pre-commit, so the ceiling was absent
from CI: an unhooked clone or `--no-verify` bypassed it entirely, and the
hook is weaker than it looks even locally — it inspects only files being
*added*, so an existing fixture that grows never trips it.
Add `scripts/check_file_sizes.py`, wired into `make lint` and therefore the
required `lint` check. It diffs against the base branch's merge base and
measures additions, modifications and renames, leaving files already
committed above the ceiling alone so no pull request fails for something it
did not touch. An unresolvable base is a hard failure rather than a silent
pass. The `lint` job now checks out with `fetch-depth: 0` to provide it.
Lower the hook's `--maxkb` from 1024 to 640 to match, and pin the two limits
equal in a unit test so they cannot drift back apart.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* ci: catch untracked oversized files in the size gate
`git diff` cannot see a newly created file until it is staged, so a local
`make check-file-sizes` passed a brand-new 700 KB file — verified against the
real script, not reasoned about. CI was unaffected (its checkout has
everything committed), but the docstring claimed the local run covered
uncommitted work, which was only true for edits to already-tracked files.
Union in `git ls-files --others --exclude-standard`, which respects
.gitignore, and pin both the untracked and the ignored case in tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* ci: exempt the generated search-seed corpora from the size ceiling
tests/fixtures/search_seed/ holds embedded corpora regenerated by
_dump_search_seed.py. Two of them are already near 1 MB and grew ~60% in one
release, so the next refresh would have hit the 640 KB ceiling and the
cheapest fix would have been raising it for the whole repository — a gate that
teaches people to edit the gate.
Exempt that one directory by path prefix instead. Outside it the largest
tracked file is ~300 KB, so 640 KB still binds where it matters, including the
examples/ case that prompted this work. Three tests pin the carve-out: a
sibling of the exempt directory is still caught, the list itself is asserted
verbatim so growth shows up in review, and every prefix must name a directory
that actually exists.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: zhanghui <zhanghui@shanda.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
GitHub had no publish path — the package was previously released from the
(now-archived) GitLab mirror. Bring publishing to the public repo:
- .github/workflows/release.yml: on a vX.Y.Z tag, build + smoke-test
(make package) and upload to PyPI via Trusted Publishing (OIDC, no stored
token), gated behind the `release` environment for manual approval. A guard
step refuses to publish when the tag != pyproject version.
- .claude/skills/release: /release documents the cut (bump version →
CHANGELOG → tag → approve → verify) and the one-time PyPI trusted-publisher
+ GitHub environment setup.
Requires two owner-only one-time steps before the first release (documented
in the workflow header and the skill): register the GitHub trusted publisher
on PyPI, and create the `release` environment with required reviewers.
Co-authored-by: zhanghui <zhanghui@shanda.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Docs workflow (`links` job) is a required status check, but its
trigger was `paths:`-filtered to markdown/docs files. A PR touching only
code never triggered it, so the required check never reported and the merge
box stayed BLOCKED forever waiting for a status that would never arrive.
Drop the `paths:` filter: `make docs-check` validates the whole doc tree
independent of the PR diff and runs in seconds, so it is cheap to report on
every PR.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
md-first memory extraction framework for AI agents.
Markdown is the single source of truth; SQLite holds state and LanceDB
provides the rebuildable vector + BM25 + scalar index. The codebase follows
a single-direction DDD layering (entrypoints -> service -> memory -> infra,
with component / core / config cross-cutting) enforced by import-linter.
Engineering surface:
- Coding conventions in .claude/rules/ (path-scoped) and workflows in
.claude/skills/ (/commit, /new-branch, /pr).
- GitHub Actions CI runs make lint + test + integration; pre-commit mirrors
the gates locally (ruff, hygiene hooks, gitlint commit-msg).
- Commit messages follow Conventional Commits, enforced by gitlint.
- make lint also enforces datetime two-zone discipline and OpenAPI drift.
zhanghui
zhanghui
Elliot Chen
Elliot Chen