slhx agent
56 lines
2.2 KiB
Markdown
56 lines
2.2 KiB
Markdown
# AGENTS.md
|
|
|
|
## Overview
|
|
|
|
`pick` is a tiny compiled Zig CLI for selecting TSV fields from stdin. It exists
|
|
as an agent-safe replacement for the safe subset of `awk '{print $N}'` and
|
|
`cut -f` when allowlist policy needs argv-obvious behavior.
|
|
|
|
## How to build
|
|
|
|
```sh
|
|
zig build
|
|
```
|
|
|
|
## How to test
|
|
|
|
```sh
|
|
zig build test
|
|
```
|
|
|
|
## Constraints
|
|
|
|
- One source file: `pick.zig`.
|
|
- No runtime dependencies, no shell execution, no filesystem reads/writes in the
|
|
tool.
|
|
- stdout is TSV/plain records only; diagnostics go to stderr.
|
|
- No regex, expressions, arithmetic, sorting, paging, JSON, color, or hidden
|
|
state.
|
|
- This is an inspection primitive. Do not add mutation or policy workflow.
|
|
|
|
## Requirement Governance
|
|
|
|
`REQUIREMENTS.md` is the requirement authority for this repository and is checked
|
|
with `redgate`. Before implementation work, read the applicable requirement row;
|
|
if none covers the durable behavior, update `REQUIREMENTS.md` first or stop and
|
|
ask for authority. When adding or changing rows, choose the ring by product
|
|
foundation, not implementation size: lower rings capture stable kernel
|
|
obligations and core contracts; higher rings compose on lower-ring obligations
|
|
and must not weaken, redefine, or bypass them. If one row mixes foundational and
|
|
optional behavior, split it before implementation.
|
|
|
|
If a change alters durable product obligations, acceptance behavior,
|
|
safety/recovery behavior, public interfaces, or verification duties, update
|
|
`REQUIREMENTS.md` in the same slice and run the relevant `redgate` checks. For
|
|
behavior intended to stick, write or update a failing BDD/TDD test, contract
|
|
test, or executable proof before implementation code; run it and record the RED
|
|
result. Implement only after the requirement row and RED proof exist. If RED
|
|
proof would be fake, unsafe, or disproportionate, state that exception before
|
|
implementation and use the strongest cheaper check.
|
|
|
|
Before final handoff, compare the user request and actual diff against
|
|
`REQUIREMENTS.md`. If there is no requirement impact, the handoff must include
|
|
exactly `REQUIREMENT IMPACT: none - <specific reason>`. If code, tests, or docs
|
|
changed but `REQUIREMENTS.md` did not, explicitly justify why no requirement row
|
|
changed.
|