{"owner":"vercel-labs","repo":"zerolang","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Contributor Notes\n\nZero is a pre-1 experiment in building an agent-first programming language.\nKeep public-facing changes honest about what works today without weakening that\npositioning.\n\n## Project Direction\n\nZero is still being shaped around the needs of agents. Breaking changes are\nacceptable when they move the language, standard library, compiler, or tooling\ncloser to that goal.\n\nDo not preserve legacy behavior by default. Prefer the clearer agent-facing\ndesign over compatibility shims, migration layers, or carrying old paths\nforward. Keep examples, docs, tests, and command contracts aligned with the new\nbehavior so the repository describes one coherent current system.\n\nThis does not mean broad churn for its own sake. Make direct changes that\nadvance Zero's agent-first goals: on-the-fly learnability, deterministic\ninspection and repair, strong standard-library coverage, exceptional developer\nexperience, and regular patterns over syntactic convenience.\n\n## Safety Expectations\n\nSecurity vulnerabilities should be expected. Zero is not ready for production\nsystems, sensitive data, or trusted infrastructure.\n\nRun and develop Zero in safe environments: isolated workspaces, disposable\ninputs, and systems where compiler crashes, malformed output, or unsafe runtime\nbehavior cannot damage production state. Treat generated artifacts and examples\nas experimental unless they have been reviewed for the specific environment\nwhere they will run.\n\n## Development\n\n- Build the local compiler with `make -C native/zero-c`.\n- Use `bin/zero` for focused checks; it execs the local native compiler at\n  `.zero/bin/zero`.\n- Keep examples runnable and docs copyable.\n- Prefer small, direct changes over broad refactors.\n- Use direct emitters for compiler output.\n- For broad local validation, run `pnpm run agent:checks`. It mirrors the CI\n  buckets in parallel, including conformance, command contracts, native test\n  shards, sanitizer smoke, and workspace checks. It uses isolated `/tmp`\n  workspaces so agents can validate uncommitted changes without local artifact\n  races.\n- Before ending any agent turn that changes the repository, run\n  `pnpm run conformance` unless `pnpm run agent:checks` already passed for the\n  same changes. If validation cannot complete, report the blocker and the\n  failing command.\n\n## Useful Checks\n\n```sh\npnpm run agent:checks\npnpm run docs:build\npnpm run conformance\npnpm run native:test\npnpm run command-contracts\n```\n\n`pnpm run agent:checks` already includes conformance. Do not run conformance\nagain after it passes unless you need to recheck later changes.\n\nShard native tests locally with `ZERO_NATIVE_TEST_SHARD=1/4 pnpm run\nnative:test:local`. PR CI runs representative native runtime cases in two\nfast shards. Scheduled and manual deep CI runs the full native runtime matrix\nin six shards, plus full conformance and full graph performance fixtures.\n\n`pnpm run conformance:local` and `pnpm run command-contracts:local` use the\naggregate validation runner. Add `-- --shard 1/4` to run one conformance phase\nshard, `-- --phases name,name` to match a focused CI phase set, `-- --list` to\nsee phases, and `-- --fail-fast` only when a narrow loop should stop at the\nfirst failing phase.\nUse `ZERO_NATIVE_TEST_SCOPE=fast` only when reproducing PR CI coverage. Leave it\nunset for the exhaustive native runtime matrix.\n`pnpm run conformance` runs the sandbox suite with four isolated conformance\ncheck workers. Local validation stays serial by default; set\n`ZERO_CONFORMANCE_CHECK_JOBS=<n>` only when measuring that path on the current\nmachine.\nValidation scripts prefer the built native compiler at `.zero/bin/zero` after\n`native-build`; set `ZERO_BIN=<path>` only when comparing another compiler\nbinary deliberately.\n\nFor focused compiler work:\n\n```sh\nbin/zero check --json <graph-input>\nbin/zero inspect --json <graph-input>\nbin/zero size --json <graph-input>\nbin/zero explain <diagnostic-code>\nbin/zero fix --plan --json <graph-backed-file-or-package>\n```\n\n## Project Layout\n\n- `native/zero-c/`: native compiler implementation.\n- `examples/`: small runnable programs and packages.\n- `conformance/`: language and CLI fixtures.\n- `docs/`: public documentation site.\n- `scripts/`: validation and release support tooling.\n\n## Public Docs Policy\n\nDocs should describe current user-facing behavior, not internal development\nhistory. Avoid release-planning language, validation-report narratives, and\nimplementation diary details in pages intended for external readers.\n\n## Releasing\n\nReleases are manual, single-branch affairs. The maintainer controls the\nchangelog voice and format.\n\nTo prepare a release:\n\n1. Create a release branch, such as `ctate/v0.1.1`.\n2. Bump the release version in `package.json`, `docs/package.json`,\n   `extensions/vscode/package.json`, and `native/zero-c/src/main.c`.\n3. Update command-contract expectations that assert the compiler version.\n4. Write the `CHANGELOG.md` entry for the new version, wrapped in\n   `<!-- release:start -->` and `<!-- release:end -->` markers.\n5. Remove the release markers from the previous release entry. Only the latest\n   release entry should have markers.\n6. Include a `### Contributors` section in the marked changelog entry. Derive\n   contributors from commit authors and `Co-authored-by` trailers since the\n   previous tag.\n7. Run focused checks before opening or updating the PR:\n\n```sh\nmake -C native/zero-c\nbin/zero --version --json\npnpm run test:zero\npnpm run command-contracts:local\npnpm run docs:build\n```\n\nThe release workflow reads the version from `package.json`, builds release\nassets, and uses the content between the changelog markers as the GitHub\nrelease body.\n"},"files":{"AGENTS.md":"# Contributor Notes\n\nZero is a pre-1 experiment in building an agent-first programming language.\nKeep public-facing changes honest about what works today without weakening that\npositioning.\n\n## Project Direction\n\nZero is still being shaped around the needs of agents. Breaking changes are\nacceptable when they move the language, standard library, compiler, or tooling\ncloser to that goal.\n\nDo not preserve legacy behavior by default. Prefer the clearer agent-facing\ndesign over compatibility shims, migration layers, or carrying old paths\nforward. Keep examples, docs, tests, and command contracts aligned with the new\nbehavior so the repository describes one coherent current system.\n\nThis does not mean broad churn for its own sake. Make direct changes that\nadvance Zero's agent-first goals: on-the-fly learnability, deterministic\ninspection and repair, strong standard-library coverage, exceptional developer\nexperience, and regular patterns over syntactic convenience.\n\n## Safety Expectations\n\nSecurity vulnerabilities should be expected. Zero is not ready for production\nsystems, sensitive data, or trusted infrastructure.\n\nRun and develop Zero in safe environments: isolated workspaces, disposable\ninputs, and systems where compiler crashes, malformed output, or unsafe runtime\nbehavior cannot damage production state. Treat generated artifacts and examples\nas experimental unless they have been reviewed for the specific environment\nwhere they will run.\n\n## Development\n\n- Build the local compiler with `make -C native/zero-c`.\n- Use `bin/zero` for focused checks; it execs the local native compiler at\n  `.zero/bin/zero`.\n- Keep examples runnable and docs copyable.\n- Prefer small, direct changes over broad refactors.\n- Use direct emitters for compiler output.\n- For broad local validation, run `pnpm run agent:checks`. It mirrors the CI\n  buckets in parallel, including conformance, command contracts, native test\n  shards, sanitizer smoke, and workspace checks. It uses isolated `/tmp`\n  workspaces so agents can validate uncommitted changes without local artifact\n  races.\n- Before ending any agent turn that changes the repository, run\n  `pnpm run conformance` unless `pnpm run agent:checks` already passed for the\n  same changes. If validation cannot complete, report the blocker and the\n  failing command.\n\n## Useful Checks\n\n```sh\npnpm run agent:checks\npnpm run docs:build\npnpm run conformance\npnpm run native:test\npnpm run command-contracts\n```\n\n`pnpm run agent:checks` already includes conformance. Do not run conformance\nagain after it passes unless you need to recheck later changes.\n\nShard native tests locally with `ZERO_NATIVE_TEST_SHARD=1/4 pnpm run\nnative:test:local`. PR CI runs representative native runtime cases in two\nfast shards. Scheduled and manual deep CI runs the full native runtime matrix\nin six shards, plus full conformance and full graph performance fixtures.\n\n`pnpm run conformance:local` and `pnpm run command-contracts:local` use the\naggregate validation runner. Add `-- --shard 1/4` to run one conformance phase\nshard, `-- --phases name,name` to match a focused CI phase set, `-- --list` to\nsee phases, and `-- --fail-fast` only when a narrow loop should stop at the\nfirst failing phase.\nUse `ZERO_NATIVE_TEST_SCOPE=fast` only when reproducing PR CI coverage. Leave it\nunset for the exhaustive native runtime matrix.\n`pnpm run conformance` runs the sandbox suite with four isolated conformance\ncheck workers. Local validation stays serial by default; set\n`ZERO_CONFORMANCE_CHECK_JOBS=<n>` only when measuring that path on the current\nmachine.\nValidation scripts prefer the built native compiler at `.zero/bin/zero` after\n`native-build`; set `ZERO_BIN=<path>` only when comparing another compiler\nbinary deliberately.\n\nFor focused compiler work:\n\n```sh\nbin/zero check --json <graph-input>\nbin/zero inspect --json <graph-input>\nbin/zero size --json <graph-input>\nbin/zero explain <diagnostic-code>\nbin/zero fix --plan --json <graph-backed-file-or-package>\n```\n\n## Project Layout\n\n- `native/zero-c/`: native compiler implementation.\n- `examples/`: small runnable programs and packages.\n- `conformance/`: language and CLI fixtures.\n- `docs/`: public documentation site.\n- `scripts/`: validation and release support tooling.\n\n## Public Docs Policy\n\nDocs should describe current user-facing behavior, not internal development\nhistory. Avoid release-planning language, validation-report narratives, and\nimplementation diary details in pages intended for external readers.\n\n## Releasing\n\nReleases are manual, single-branch affairs. The maintainer controls the\nchangelog voice and format.\n\nTo prepare a release:\n\n1. Create a release branch, such as `ctate/v0.1.1`.\n2. Bump the release version in `package.json`, `docs/package.json`,\n   `extensions/vscode/package.json`, and `native/zero-c/src/main.c`.\n3. Update command-contract expectations that assert the compiler version.\n4. Write the `CHANGELOG.md` entry for the new version, wrapped in\n   `<!-- release:start -->` and `<!-- release:end -->` markers.\n5. Remove the release markers from the previous release entry. Only the latest\n   release entry should have markers.\n6. Include a `### Contributors` section in the marked changelog entry. Derive\n   contributors from commit authors and `Co-authored-by` trailers since the\n   previous tag.\n7. Run focused checks before opening or updating the PR:\n\n```sh\nmake -C native/zero-c\nbin/zero --version --json\npnpm run test:zero\npnpm run command-contracts:local\npnpm run docs:build\n```\n\nThe release workflow reads the version from `package.json`, builds release\nassets, and uses the content between the changelog markers as the GitHub\nrelease body.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Contributor Notes\n\nZero is a pre-1 experiment in building an agent-first programming language.\nKeep public-facing changes honest about what works today without weakening that\npositioning.\n\n## Project Direction\n\nZero is still being shaped around the needs of agents. Breaking changes are\nacceptable when they move the language, standard library, compiler, or tooling\ncloser to that goal.\n\nDo not preserve legacy behavior by default. Prefer the clearer agent-facing\ndesign over compatibility shims, migration layers, or carrying old paths\nforward. Keep examples, docs, tests, and command contracts aligned with the new\nbehavior so the repository describes one coherent current system.\n\nThis does not mean broad churn for its own sake. Make direct changes that\nadvance Zero's agent-first goals: on-the-fly learnability, deterministic\ninspection and repair, strong standard-library coverage, exceptional developer\nexperience, and regular patterns over syntactic convenience.\n\n## Safety Expectations\n\nSecurity vulnerabilities should be expected. Zero is not ready for production\nsystems, sensitive data, or trusted infrastructure.\n\nRun and develop Zero in safe environments: isolated workspaces, disposable\ninputs, and systems where compiler crashes, malformed output, or unsafe runtime\nbehavior cannot damage production state. Treat generated artifacts and examples\nas experimental unless they have been reviewed for the specific environment\nwhere they will run.\n\n## Development\n\n- Build the local compiler with `make -C native/zero-c`.\n- Use `bin/zero` for focused checks; it execs the local native compiler at\n  `.zero/bin/zero`.\n- Keep examples runnable and docs copyable.\n- Prefer small, direct changes over broad refactors.\n- Use direct emitters for compiler output.\n- For broad local validation, run `pnpm run agent:checks`. It mirrors the CI\n  buckets in parallel, including conformance, command contracts, native test\n  shards, sanitizer smoke, and workspace checks. It uses isolated `/tmp`\n  workspaces so agents can validate uncommitted changes without local artifact\n  races.\n- Before ending any agent turn that changes the repository, run\n  `pnpm run conformance` unless `pnpm run agent:checks` already passed for the\n  same changes. If validation cannot complete, report the blocker and the\n  failing command.\n\n## Useful Checks\n\n```sh\npnpm run agent:checks\npnpm run docs:build\npnpm run conformance\npnpm run native:test\npnpm run command-contracts\n```\n\n`pnpm run agent:checks` already includes conformance. Do not run conformance\nagain after it passes unless you need to recheck later changes.\n\nShard native tests locally with `ZERO_NATIVE_TEST_SHARD=1/4 pnpm run\nnative:test:local`. PR CI runs representative native runtime cases in two\nfast shards. Scheduled and manual deep CI runs the full native runtime matrix\nin six shards, plus full conformance and full graph performance fixtures.\n\n`pnpm run conformance:local` and `pnpm run command-contracts:local` use the\naggregate validation runner. Add `-- --shard 1/4` to run one conformance phase\nshard, `-- --phases name,name` to match a focused CI phase set, `-- --list` to\nsee phases, and `-- --fail-fast` only when a narrow loop should stop at the\nfirst failing phase.\nUse `ZERO_NATIVE_TEST_SCOPE=fast` only when reproducing PR CI coverage. Leave it\nunset for the exhaustive native runtime matrix.\n`pnpm run conformance` runs the sandbox suite with four isolated conformance\ncheck workers. Local validation stays serial by default; set\n`ZERO_CONFORMANCE_CHECK_JOBS=<n>` only when measuring that path on the current\nmachine.\nValidation scripts prefer the built native compiler at `.zero/bin/zero` after\n`native-build`; set `ZERO_BIN=<path>` only when comparing another compiler\nbinary deliberately.\n\nFor focused compiler work:\n\n```sh\nbin/zero check --json <graph-input>\nbin/zero inspect --json <graph-input>\nbin/zero size --json <graph-input>\nbin/zero explain <diagnostic-code>\nbin/zero fix --plan --json <graph-backed-file-or-package>\n```\n\n## Project Layout\n\n- `native/zero-c/`: native compiler implementation.\n- `examples/`: small runnable programs and packages.\n- `conformance/`: language and CLI fixtures.\n- `docs/`: public documentation site.\n- `scripts/`: validation and release support tooling.\n\n## Public Docs Policy\n\nDocs should describe current user-facing behavior, not internal development\nhistory. Avoid release-planning language, validation-report narratives, and\nimplementation diary details in pages intended for external readers.\n\n## Releasing\n\nReleases are manual, single-branch affairs. The maintainer controls the\nchangelog voice and format.\n\nTo prepare a release:\n\n1. Create a release branch, such as `ctate/v0.1.1`.\n2. Bump the release version in `package.json`, `docs/package.json`,\n   `extensions/vscode/package.json`, and `native/zero-c/src/main.c`.\n3. Update command-contract expectations that assert the compiler version.\n4. Write the `CHANGELOG.md` entry for the new version, wrapped in\n   `<!-- release:start -->` and `<!-- release:end -->` markers.\n5. Remove the release markers from the previous release entry. Only the latest\n   release entry should have markers.\n6. Include a `### Contributors` section in the marked changelog entry. Derive\n   contributors from commit authors and `Co-authored-by` trailers since the\n   previous tag.\n7. Run focused checks before opening or updating the PR:\n\n```sh\nmake -C native/zero-c\nbin/zero --version --json\npnpm run test:zero\npnpm run command-contracts:local\npnpm run docs:build\n```\n\nThe release workflow reads the version from `package.json`, builds release\nassets, and uses the content between the changelog markers as the GitHub\nrelease body.\n","category":"root","tokens":1420}]}