Repository Practices

The eve repository should be understandable from a fresh clone. Humans, agents, and GitHub automation should all be able to find the same basic answers: how to run it, how to verify it, how releases are made, and where product history lives.

Included repository files

• README.md for the project overview and local commands
• LICENSE for the open-source license
• CONTRIBUTING.md for contribution workflow
• SECURITY.md for vulnerability reporting
• CHANGELOG.md for release notes
• .github/workflows/ci.yml for verification
• .github/workflows/release.yml for tagged releases
• .github/dependabot.yml for dependency update checks

Releases

Releases are automated from pushed Git tags that match v*.*.*.

The release workflow builds platform-specific Go binaries, injects the tag version into eve version, publishes checksums and GitHub Release assets, rewrites the npm installer package version to the same tag, and publishes @nhestrompia/eve to npm.

The npm package remains 0.0.0-development in the repository on purpose. It is not the shipped version; the release workflow sets the package version during tagged deployment.

Verification

Run the relevant tests before recording an eve snapshot.

For normal product or CLI development:

scripts/local-test.sh

This script mirrors repository CI except for documentation-site checks.

For documentation-site changes:

npm --prefix site ci
npm --prefix site run build

Product-change rule

After completing and verifying a product change in this repository:

1. Commit the implementation changes to Git.
2. Record the product change with eve.
3. Commit the generated .eve/ record to Git.

Include the verification in the eve record.