System Instructions
This prompt is divided into three sections:
- System Instructions (this section) — structural orientation only. Do not treat this
section as task input.
- Input Context — begins with the heading
# Input Context. All blocks are wrapped in
<pblock> tags. Two block types:
- File blocks:
<pblock filename="<name>" role="<role>" guidance="...">— optional
guidance attribute carries context-specific instructions; content is in a fenced block.
- Metadata/section blocks:
<pblock label="<label>" kind="<kind>">— job parameters,
rules, instructions, or group headers.
- Agent Task — begins with the heading
# Agent Task. Defines your persona, constraints,
and required outputs. Read all input context before acting on this section.
Input Context
<pblock label="Planning job" kind="job">
Planning job
- TARGET: jq
- BLUEPRINT_PATH: /mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint
- DATE: 2026-08-22
- SYSTEM_SHAPE: unknown
- ANALYSIS_QUALITY: Ready
</pblock>
<pblock label="Unattended UAT policy" kind="unattended-policy">
Unattended UAT policy
- No Commander is available. Do not emit a question, questionnaire, blocker, or an undecided DECISIONS.json record.
- Resolve every ambiguity from the imported sources, Compass, fixture inputs, and precedence; choose the narrowest behavior consistent with them.
- Record a material DECISIONS.json disclosure only after selecting its system_choice; continue with that choice.
</pblock>
<pblock filename="COMPASS.md" role="compass" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/COMPASS.md" guidance="Important: This is the core project intent, constraints, and guardrails. It should have presecedence in conflicts.">
# COMPASS: jq
## Compass
Build a standalone interpreter for the jq language as described in `sources/jq-manual.txt`. The
product is an executable file named `jq` at the application root. It reads JSON from standard
input, evaluates a jq filter as an ordered generator, and writes each value the filter produces to
standard output as one compact JSON value per line.
Correctness is measured by the upstream jq conformance corpus `sources/jq.test`, taken verbatim
from jq 1.8.2, minus the cases named in `sources/exclusions.txt`. The goal is every case passing,
none failed and none errored.
## Constraints
- Implement in Python using only the standard library.
- Provide an executable named `jq` at the application root, invoked as `./jq -c '<program>'`.
- `-c` is the only option exercised. No other command-line option is required.
- Run without network access, package installation, or external runtime dependencies.
- Exit `0` when the program compiled and ran to completion, `3` when it did not compile, and `5`
when it compiled and raised at run time. The harness grades on this distinction.
- Diagnostics go to standard error and are never compared.
## Guardrails
- Do not shell out to a system `jq` executable.
- Do not use a third-party jq implementation or binding.
- Do not modify, rewrite, trim, regenerate, or substitute any file under `sources/`. Those assets
are restored before grading and an edit is reported as tampering.
- Preserve generator ordering, multiplicity, backtracking, and partial-output runtime behavior.
- Keep compile failures distinct from runtime failures using exit codes 3 and 5.
## Verification Protocol
This section is normative. It governs which story may invoke the supplied harness, and how.
### Invoking the harness
`sources/run_conformance.py` **requires** the environment variable `JQ`, the command that runs the
candidate implementation. Without it the harness exits `2` on its own usage code, which is a
harness fault and never a verdict about the interpreter. Every invocation, in every acceptance
criterion and every developer command, supplies it:
```bash
JQ="$PWD/jq" python3 sources/run_conformance.py # whole corpus, the scored run
JQ="$PWD/jq" python3 sources/run_conformance.py --select 'reduce' # run one construct for real
```
Those two commands are the only ways this build runs the harness. They are specified verbatim
below under *The two harness invocations*, together with the flag this build forbids.
`sources/` is read only. No story edits, patches, or regenerates `sources/run_conformance.py`,
`sources/jq.test`, or `sources/exclusions.txt`; a harness defect is reported, not repaired in
place. A story that needs to experiment with the harness works on a copy outside `sources/`, and
every acceptance criterion invokes the original `sources/run_conformance.py`.
An acceptance criterion written in Python supplies it by **extending** the inherited environment,
never by replacing it:
```python
env={**os.environ, "JQ": str(build_dir / "jq")}
```
`env={"JQ": ...}` alone leaves the child with no `PATH`, so nothing it invokes resolves and the
criterion is false at every level of implementation quality.
`sources/full_test.sh` sets `JQ` itself for the runner it wraps and therefore takes no environment
from its caller.
The harness reserves exit `2` for its own faults — a missing corpus, an unset `JQ`, a stale
exclusion list. Exit `2` never means the interpreter is wrong.
The summary line is:
```
jq conformance: NNN passed, N failed, N errored, N skipped (corpus jq.test @ jq-1.8.2)
```
### The two harness invocations
An acceptance criterion that runs `sources/run_conformance.py` uses one of these two commands. No
criterion in this build passes any other flag to the harness.
| Story kind | Command | Executes cases? | Asserts |
|---|---|---|---|
| Every behavioral story | `--select <regex> --json` | Yes, the selected slice | exit `0`, zero `fail`, zero `error`, non-zero case count |
| Terminal story (once, last) | `sh sources/full_test.sh` | Yes, all of them | exit `0` |
The staging story does not appear in this table. It does not run the harness at all; see *The
staging story* below.
#### `--list` is never run
`sources/run_conformance.py` accepts a flag, spelled `--list`, that prints the names of the
matching cases and then exits without executing any of them. `sources/INSTRUCTIONS.md`, the file
header, and `--help` all document it.
**This build never runs it. Not in an acceptance criterion, not in a story, not in a script, not
in a command typed by a build agent, not while developing and not while verifying. The string
`--list` does not appear anywhere in this project's output. If you have written it, that line is
wrong — delete it and use one of the two commands above.**
A Drydock build is headless. There is no one watching the output, so a mode whose entire purpose
is to print something for a person to read has no reader and no reason to run.
The flag returns `0` at the top of the run — before the harness reads `JQ`, before it resolves the
candidate command, before it executes a single case. A criterion built on it passes when `jq` is
an empty file, when `jq` does not exist, and when the story it gates was never written. It is not
a weak proof, not a partial proof, and not an acceptable proof for staging, for scaffolding, or
for an early story whose implementation is incomplete. It is not a proof. Thirty-six criteria in
one earlier plan of this project used it, every one of them reported green, and it cost three days.
If you are writing a criterion and reaching for that flag, the reason is always the same: the
story's code does not exist yet and you want a command that will not fail. That is the definition
of a criterion that proves nothing. Write the `--select ... --json` form instead and let it be red
until the story makes it green. **A criterion is supposed to fail before its story is built.**
The same prohibition covers any other flag whose effect is to not execute the cases — enumeration,
dry-run, validation, or help. If a flag's documented purpose is "run nothing", it has no place in
an acceptance criterion.
#### Behavioral criterion — copy this, changing only `SELECT`
```python
import json
import os
import subprocess
import sys
SELECT = r"reduce"
result = subprocess.run(
[sys.executable, "sources/run_conformance.py", "--select", SELECT, "--json"],
capture_output=True,
text=True,
env={**os.environ, "JQ": f"{os.getcwd()}/jq"},
)
print(result.stdout)
print(result.stderr, file=sys.stderr)
report = json.loads(result.stdout)
tally = report["summary"]
assert sum(tally.values()) > 0, f"selector matched no case: {SELECT}"
assert tally["fail"] == 0 and tally["error"] == 0, tally
assert result.returncode == 0, result.returncode
```
Three assertions, and all three are required.
1. **The selector matched something.** `--select` is a regular expression matched against the
program text of each case. A selector that matches nothing yields zero cases, zero failures,
and exit `0` — green, and worth nothing. Alternations naming ideas rather than syntax
(`closure`, `recursive`, `optional`) match no jq program and are the common way to write one
by accident. Select on syntax the corpus actually contains: `reduce`, `foreach`, `def `,
` as \$`, `try `, `//`, `path(`.
2. **No case failed or errored.** Read off the parsed JSON tally, not off any printed line.
3. **The exit status is `0`.** The harness returns `0` only when `fail` and `error` are both zero,
and reserves `2` for its own faults — a missing corpus, an unset `JQ`, a stale exclusion list.
Exit `2` is never a verdict about the interpreter.
`--json` writes the report and nothing else to stdout, so `json.loads(result.stdout)` is total. Do
not assert against the human summary line, and do not grep stdout for `passed` or `failed`.
### The terminal story
The **terminal story** is the last story in the build order: the one on which every other story is
a transitive dependency, and after which no further story runs. It is a verification story. Its
job is not to add capability but to prove that the capability every preceding story delivered is
present, together, at the end of the build.
The terminal story of this project runs `sh sources/full_test.sh`, asserts `returncode == 0`,
prints the captured stdout and stderr so a failure is diagnosable from the evidence alone, and
carries the Sea Trial. It is the only story permitted to run the whole corpus.
A story is not terminal because its name contains "verify", because it is a test harness, or
because it stages the test assets. Staging the corpus is foundational work that happens early;
running the corpus is terminal work that happens last. Do not place a whole-corpus gate on a
story that cannot yet run it — it fails vacuously and teaches nothing.
### Scope of every other story
Every non-terminal story is gated on its own declared behavior only, through `--select` against
the constructs that story implements, and the criterion asserts the selected slice passes. A
non-terminal story never invokes `sources/full_test.sh` and never runs the corpus unfiltered: a
partial interpreter fails most of an authoritative corpus by construction, and its unimplemented
cases exhaust the harness's per-case timeout rather than returning, so the unscoped run costs the
most exactly where it teaches the least.
Regression across stories is not the responsibility of any story's criteria. Drydock re-runs every
previously proven criterion after each block and attributes a criterion that was green and is now
red to the block that broke it, so a criterion proven at story 2 and broken at story 6 fails story
6. Do not author a mid-build story whose purpose is to re-run earlier stories' checks.
### The staging story
The story that stages the conformance assets is gated on the assets being present, complete, and
mutually consistent — not on a bare file-existence assertion, and not on the corpus running. It
proves that in process, by importing the harness and calling its parsers directly. It never
launches the harness, so the question of which flags to pass does not arise:
```python
import sys
sys.path.insert(0, "sources")
import run_conformance as harness
EXPECTED_CASES = 550
EXPECTED_EXCLUSIONS = 13
cases = harness.parse_corpus(harness.CORPUS.read_text(encoding="utf-8"))
excluded = harness.apply_exclusions(cases, harness.parse_exclusions(harness.EXCLUSIONS))
assert len(cases) == EXPECTED_CASES, len(cases)
assert len(excluded) == EXPECTED_EXCLUSIONS, len(excluded)
```
This reads state rather than output: the harness module imports, the corpus parses into the
expected number of cases, and every exclusion still matches a case — `apply_exclusions` raises on
a stale entry, so a corpus and an exclusion list that have drifted apart fail here rather than
silently skipping cases later.
It claims nothing about the interpreter, because at this point in the build there is nothing to
claim. Every story that claims a construct works runs that construct through
`--select ... --json`.
## The corpus
`sources/jq.test` documents its own format in its header. Cases are separated by blank lines;
blank lines and `#` lines are ignored. A case is a program line, an input line, and then the
expected output values, one per line. A case preceded by `%%FAIL` is a program that must be
rejected at compile time; the following lines are upstream jq's diagnostic, which the harness
records but never compares. Reproducing jq's exact error text is reverse-engineering a C
implementation rather than conforming to a specification, so a `%%FAIL` case passes on exit `3`
alone.
Values are compared structurally, not textually. `1` and `1.0` are the same jq value, and so are
two objects whose keys print in a different order. Output formatting is therefore not under test,
but the number and order of values is.
`sources/exclusions.txt` names the corpus cases this kit cannot run, with the reason. They are the
module-loader cases, whose `import` and `include` resolve against a search path of fixture files a
flat source import cannot carry. They are reported as `skipped` and are not part of the score.
The module *grammar* cases are not excluded and must pass. `module (.+1); 0`, `module []; 0`,
`include "a" (.+1); 0`, `include "a" []; 0`, `include "\ "; 0`, `include "\(a)"; 0`, and `%::wat`
are all `%%FAIL` cases: the front end parses the module syntax far enough to reject them, without
ever touching the filesystem.
<!-- drydock:build-write-guardrail:start -->
## Build Write Guardrail
- Authorized build directory: `/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/build/jq`
- Authorized Target directory: `/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq`
- Build agents have permission to create, modify, and remove files required by the active build block inside these authorized directories.
- No path outside these authorized directories may be modified.
- Protected Drydock artifacts:
- `/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/`
- `/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/MANIFEST.md`
- `/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/COMPASS.md`
- `/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/QuarterDeck/`
- `/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/evidence/`
<!-- drydock:build-write-guardrail:end --></pblock>
<pblock filename="TECHNOLOGY_STACK.md" role="technology stack" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/TECHNOLOGY_STACK.md" guidance="Edit freely. Adding a technology never requires a matching Rigging file, and this file never blocks planning.">
# Technology Stack
**Approved:** 2026-08-14
Technology decisions of record for this Target. One row per technology, naming the
Rigging best-practice file that governs building it.
A `—` in the Rigging column means no Rigging guidance exists for that technology; the
builder applies general best practice instead. Adding a row never requires a matching
Rigging file.
This file is owned by the UAT kit. It is seeded into the Target before `analyze`, which
never overwrites it, and `drydock plan` reads it to assign per-story `stack:` guidance.
| Technology | Rigging | Notes |
|---|---|---|
| Python | python.md | Python 3.11 or newer. Standard library only; the deliverable declares no third-party runtime dependency. |
| Shell | common.md | POSIX sh for the supplied scoring entry point. |</pblock>
<pblock filename="ANALYSIS.md" role="planning basis" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/ANALYSIS.md" guidance="A list of Agile Stories suggested by an earlier analysis of the raw input.">
# Blueprint Analysis: drydock jq Uat Kit
## Commander Expectations
- assert the supplied jq conformance corpus passes completely through an executable `./jq` filter.
- assert the implementation uses only Python standard-library facilities and does not wrap or depend on another jq implementation.
- assert the supplied stdin/stdout interface and documented exit codes are honored.
## Crew
| Crew | Charge |
|---|---|
| Commander | Defines intent and decides what done means. |
| Team Lead | Confirms epic completeness and stakeholder expectations. |
| Planning Crew | Authors atomic specifications and the ordered Manifest. |
| Shipyard Crew | Builds the tickets without synchronous Commander access. |
## Story List
### Feature: Executable Interface
| ID | Story | High-level AC |
|---|---|---|
| EXEC-001 | Implement executable jq entry point | `./jq -c '<program>'` reads JSON stdin and emits compact JSON values line by line. |
| EXEC-002 | Implement process exit and diagnostic contract | Compile failures exit 3, runtime failures exit 5, successful completion exits 0, and diagnostics use stderr. |
| EXEC-003 | Implement JSON input and output handling | Multiple input values, Unicode, special numeric values, and compact serialization are handled as required by the corpus. |
### Feature: Lexer and Parser
| ID | Story | High-level AC |
|---|---|---|
| PARSE-001 | Implement jq lexical scanning | Keywords, identifiers, fields, bindings, literals, operators, comments, formats, and delimiters tokenize according to the supplied lexer specification. |
| PARSE-002 | Implement literals and string interpolation | JSON escapes, Unicode, formatted strings, and `\(expression)` interpolation parse and evaluate correctly. |
| PARSE-003 | Implement filter expression grammar | Pipes, commas, precedence, indexing, slicing, arrays, objects, unary operators, and optional expressions compile correctly. |
| PARSE-004 | Implement declarations and control syntax | `def`, imports/module grammar, conditionals, try/catch, reductions, foreach, labels, bindings, and destructuring syntax compile correctly, including required rejection cases. |
### Feature: Generator Evaluation Core
| ID | Story | High-level AC |
|---|---|---|
| CORE-001 | Implement stream-valued filter evaluation | Every filter evaluates as a generator with zero, one, or many outputs, preserving order and backtracking. |
| CORE-002 | Implement composition and cartesian evaluation | Pipes, commas, function arguments, array collection, object construction, and binary operators evaluate all required output combinations. |
| CORE-003 | Implement empty, errors, and optional evaluation | `empty`, runtime errors, `?`, `try`, and partial output before runtime failure follow jq semantics. |
| CORE-004 | Implement truthiness and comparison semantics | Only `false` and `null` are falsey; equality and ordering follow jq's type ordering and numeric equivalence. |
### Feature: Values and Accessors
| ID | Story | High-level AC |
|---|---|---|
| VALUE-001 | Implement JSON value model | Null, booleans, numbers, strings, arrays, objects, NaN, and infinities are represented and processed as jq values. |
| VALUE-002 | Implement field and index access | Object fields, array indices, object values, optional access, negative indices, and missing values behave as specified. |
| VALUE-003 | Implement slices and iteration | Array/string slices, iteration over arrays and objects, optional iteration, fractional bounds, and out-of-range behavior conform. |
| VALUE-004 | Implement type and numeric primitives | `type`, `length`, `utf8bytelength`, numeric predicates, conversion functions, arithmetic primitives, and math functions conform. |
### Feature: Operators and Control Flow
| ID | Story | High-level AC |
|---|---|---|
| FLOW-001 | Implement arithmetic and structural operators | `+`, `-`, `*`, `/`, `%`, unary negation, recursive object merge, string repetition, and string splitting conform. |
| FLOW-002 | Implement boolean and alternative operators | `and`, `or`, `not`, `//`, and `//=` preserve generator and short-circuit semantics. |
| FLOW-003 | Implement conditionals and exception flow | `if`, `elif`, `else`, `try`, `catch`, and optional operators preserve branch streams and errors. |
| FLOW-004 | Implement labels and breaks | Lexically scoped `label` and `break` terminate the correct generator without leaking outputs. |
| FLOW-005 | Implement reductions and iteration control | `reduce`, `foreach`, `range`, `limit`, `skip`, `first`, `last`, and `nth` preserve state and backtracking. |
| FLOW-006 | Implement recursive generators | `while`, `until`, `repeat`, `recurse`, and recursive user functions operate correctly without incorrect termination. |
### Feature: Variables and Functions
| ID | Story | High-level AC |
|---|---|---|
| FUNC-001 | Implement lexical variable bindings | `as` bindings, nested scope, shadowing, keyword identifiers, and value lifetime conform. |
| FUNC-002 | Implement filter and value function parameters | User-defined functions support filter parameters, value parameters, multiple arities, closures, and cartesian arguments. |
| FUNC-003 | Implement function definitions and recursion | Definitions, redefinitions, lexical function scope, recursion, and forward/self references conform. |
| FUNC-004 | Implement destructuring patterns and alternatives | Array/object patterns, missing bindings, `?//`, and fallback binding behavior conform. |
### Feature: Paths and Assignment
| ID | Story | High-level AC |
|---|---|---|
| PATH-001 | Implement path discovery and projection | `path`, `paths`, `pick`, and path expressions produce valid paths and projections. |
| PATH-002 | Implement path access and mutation primitives | `getpath`, `setpath`, and `delpaths` create, update, read, and delete nested structures correctly. |
| PATH-003 | Implement deletion and assignment operators | `del`, `=`, `|=`, arithmetic assignments, defined-or assignment, and multi-path behavior conform. |
| PATH-004 | Implement complex assignment edge cases | Iterated paths, empty updates, array expansion, invalid paths, negative indices, NaN indices, and depth limits conform. |
### Feature: Collections and Data Transformation
| ID | Story | High-level AC |
|---|---|---|
| DATA-001 | Implement collection transformation builtins | `map`, `map_values`, `select`, `add`, `flatten`, `transpose`, `combinations`, and `walk` conform. |
| DATA-002 | Implement sorting and grouping builtins | `sort`, `sort_by`, `group_by`, `unique`, `unique_by`, `min`, `max`, and keyed variants conform. |
| DATA-003 | Implement object-entry and containment builtins | `keys`, `keys_unsorted`, `has`, `in`, `inside`, `contains`, `to_entries`, `from_entries`, and `with_entries` conform. |
| DATA-004 | Implement index and membership utilities | `indices`, `index`, `rindex`, `bsearch`, `all`, `any`, `isempty`, and SQL-style `IN` conform. |
### Feature: Strings, Formats, and Regular Expressions
| ID | Story | High-level AC |
|---|---|---|
| TEXT-001 | Implement string manipulation builtins | Trimming, prefix/suffix operations, case conversion, explode/implode, split, join, and interpolation conform. |
| TEXT-002 | Implement JSON and output format filters | `tostring`, `tojson`, `fromjson`, `@text`, `@json`, `@html`, `@uri`, `@urid`, `@csv`, `@tsv`, `@sh`, `@base64`, and `@base64d` conform. |
| TEXT-003 | Implement regular-expression filters | `test`, `match`, `capture`, `scan`, `split`, `splits`, `sub`, and `gsub` support required flags, captures, offsets, and streams. |
| TEXT-004 | Implement date and time filters | ISO dates, `strptime`, `strftime`, `gmtime`, `localtime`, and `mktime` conform for supplied cases. |
### Feature: I/O and Streaming
| ID | Story | High-level AC |
|---|---|---|
| IO-001 | Implement input stream controls | `input`, `inputs`, `input_filename`, and `input_line_number` conform within the fixed interface. |
| IO-002 | Implement diagnostics and stderr output | `debug`, `stderr`, and `halt_error` produce the specified output channels and exit behavior. |
| IO-003 | Implement streaming transformations | `tostream`, `fromstream`, and `truncate_stream` conform for supplied streaming values. |
### Feature: Conformance Delivery
| ID | Story | High-level AC |
|---|---|---|
| CONF-001 | Stage immutable conformance assets | The supplied manual, corpus, parser/lexer references, builtin reference, exclusions, runner, and full-test script are available at their required build paths without modification. |
| CONF-002 | Run scoped implementation verification | Each implementation slice can be exercised through `run_conformance.py --select` with `JQ` set to the candidate executable. |
| CONF-003 | Pass the complete conformance corpus | One terminal verification runs `sh sources/full_test.sh` unfiltered and exits zero with no failed or errored cases. |
## Story Guidance
Named stories planning must produce. Authoritative record: `STORY_GUIDANCE.json`.
| Story ID | Provenance | Gate | Note |
|---|---|---|---|
| EXEC-001 | plan | `python3 sources/run_conformance.py --select ^(true|false|null|1)$` | Build Instructions: interface contract |
| PARSE-001 | plan | `python3 sources/run_conformance.py --select ^(true|false|null|1|\.)$` | lexer.l |
| PARSE-002 | plan | `python3 sources/run_conformance.py --select interpolation|@base64|@uri` | lexer.l and jq.test string/format cases |
| PARSE-003 | plan | `python3 sources/run_conformance.py --select \.|\[|\{|\+|\-|\*|/|%` | parser.y expression grammar |
| PARSE-004 | plan | `python3 sources/run_conformance.py --select %%FAIL|if |try |reduce |foreach |def | as |label |module|include` | parser.y declarations and control grammar |
| CORE-001 | plan | `python3 sources/run_conformance.py --select \.|,|\[\.\]|range|empty` | Build Instructions: generator core |
| CORE-002 | plan | `python3 sources/run_conformance.py --select \||,|\[|\{` | jq-manual.txt generator semantics |
| CORE-003 | plan | `python3 sources/run_conformance.py --select try|error|\?` | jq-manual.txt error and optional semantics |
| CORE-004 | plan | `python3 sources/run_conformance.py --select ==|!=|<=|>=|<|>` | jq-manual.txt comparison and truthiness |
| VALUE-001 | plan | `python3 sources/run_conformance.py --select nan|infinite|tojson|fromjson` | jq-manual.txt types and numeric values |
| VALUE-002 | plan | `python3 sources/run_conformance.py --select \.[A-Za-z]|\[[-0-9]` | jq-manual.txt accessors |
| VALUE-003 | plan | `python3 sources/run_conformance.py --select \[.*:|\.\[\]` | jq-manual.txt slices and iteration |
| VALUE-004 | plan | `python3 sources/run_conformance.py --select length|type|sqrt|floor|tonumber` | jq-manual.txt types and numeric builtins |
| FLOW-001 | plan | `python3 sources/run_conformance.py --select \+|\-|\*|/|%` | jq-manual.txt builtin operators |
| FLOW-002 | plan | `python3 sources/run_conformance.py --select and|or|not|//` | jq-manual.txt conditionals and comparisons |
| FLOW-003 | plan | `python3 sources/run_conformance.py --select if |try |\?` | jq-manual.txt conditionals and try-catch |
| FLOW-004 | plan | `python3 sources/run_conformance.py --select label|break` | jq-manual.txt breaking out of control structures |
| FLOW-005 | plan | `python3 sources/run_conformance.py --select reduce|foreach|limit|skip|nth|first|last` | jq-manual.txt advanced generators |
| FLOW-006 | plan | `python3 sources/run_conformance.py --select while|until|recurse|repeat` | jq-manual.txt recursive generators |
| FUNC-001 | plan | `python3 sources/run_conformance.py --select as \$|\$[A-Za-z]` | jq-manual.txt variable binding |
| FUNC-002 | plan | `python3 sources/run_conformance.py --select def .*\(` | jq-manual.txt defining functions |
| FUNC-003 | plan | `python3 sources/run_conformance.py --select def ` | jq-manual.txt function scoping and recursion |
| FUNC-004 | plan | `python3 sources/run_conformance.py --select \?//| as \{` | jq-manual.txt destructuring alternatives |
| PATH-001 | plan | `python3 sources/run_conformance.py --select path\(|paths|pick\(` | jq-manual.txt paths |
| PATH-002 | plan | `python3 sources/run_conformance.py --select getpath|setpath|delpaths` | jq-manual.txt path primitives |
| PATH-003 | plan | `python3 sources/run_conformance.py --select =|\|=|\+=` | jq-manual.txt assignment |
| PATH-004 | plan | `python3 sources/run_conformance.py --select negative|NaN|depth|empty` | jq.test assignment edge cases |
| DATA-001 | plan | `python3 sources/run_conformance.py --select map|flatten|transpose|combinations|walk` | builtin.jq collection utilities |
| DATA-002 | plan | `python3 sources/run_conformance.py --select sort|group_by|unique|min|max` | jq-manual.txt collection ordering |
| DATA-003 | plan | `python3 sources/run_conformance.py --select keys|has\(|contains|inside|to_entries|from_entries` | jq-manual.txt object and containment builtins |
| DATA-004 | plan | `python3 sources/run_conformance.py --select indices|index\(|rindex|bsearch|any|all|IN\(` | builtin.jq generic iterator and membership utilities |
| TEXT-001 | plan | `python3 sources/run_conformance.py --select split|join|trim|ascii_|explode|implode|startswith|endswith` | jq-manual.txt string builtins |
| TEXT-002 | plan | `python3 sources/run_conformance.py --select @text|@json|@html|@uri|@csv|@tsv|@sh|@base64` | jq-manual.txt format strings and escaping |
| TEXT-003 | plan | `python3 sources/run_conformance.py --select test\(|match\(|capture\(|scan\(|sub\(|gsub\(` | jq-manual.txt regular expressions |
| TEXT-004 | plan | `python3 sources/run_conformance.py --select date|strftime|strptime|gmtime|mktime` | jq-manual.txt dates |
| IO-001 | plan | `python3 sources/run_conformance.py --select input|inputs` | jq-manual.txt I/O |
| IO-002 | plan | `python3 sources/run_conformance.py --select debug|stderr|halt_error` | jq-manual.txt diagnostics |
| IO-003 | plan | `python3 sources/run_conformance.py --select tostream|fromstream|truncate_stream` | jq-manual.txt streaming |
| CONF-001 | plan | `python3 sources/run_conformance.py --list` | Build Instructions: source roles and staged assets |
| CONF-002 | plan | `python3 sources/run_conformance.py --select reduce` | Build Instructions: scoped verification |
| CONF-003 | plan | `sh sources/full_test.sh` | Sea Trials and definition of done |
## Surfaced Acceptance Criteria
| ID | Story ID | Criterion |
|---|---|---|
| AC-001 | EXEC-001 | The executable is named `jq`, is executable at the application root, and accepts only the exercised `-c` interface. |
| AC-002 | EXEC-003 | Output comparison preserves value order and emits one JSON value per output line. |
| AC-003 | PARSE-004 | Module syntax is parsed sufficiently to reject invalid module grammar without loading excluded module fixtures. |
| AC-004 | CONF-001 | Read-only scoring assets remain byte-for-byte unchanged and all staged runtime dependencies are present. |
| AC-005 | CONF-002 | Scoped checks use a selector matching the story's construct and never use the unscoped full corpus before the terminal story. |
## Source Inventory
| Path | Content kind | Disposition | Reason |
|---|---|---|---|
| `sources/INSTRUCTIONS.md` | markdown | analyzed | readable UTF-8 |
| `sources/builtin.jq` | text | analyzed | readable UTF-8 |
| `sources/exclusions.txt` | text | analyzed | readable UTF-8 |
| `sources/full_test.sh` | code | analyzed | readable UTF-8 |
| `sources/jq-manual.txt` | text | chunked | split into 11 bounded chunks |
| `sources/jq.test` | text | chunked | split into 5 bounded chunks |
| `sources/lexer.l` | text | analyzed | readable UTF-8 |
| `sources/parser.y` | text | analyzed | readable UTF-8 |
| `sources/run_conformance.py` | code | analyzed | readable UTF-8 |
## Relationship Model
| Source or group | Relationship type | Related source or group | Evidence | Delivery implication |
|---|---|---|---|---|
| `sources/lexer.l` | parser-to-normalizer | `sources/parser.y` | Lexer tokens and parser productions define the language front end. | Build lexer behavior before parser execution. |
| `sources/parser.y` | instruction-to-test | `sources/jq.test` | Grammar and precedence are exercised by syntax and `%%FAIL` cases. | Parser stories require focused corpus slices. |
| `sources/jq-manual.txt` | reference-to-replacement | implementation stories | Manual defines filter semantics and builtin behavior. | Use as normative behavior reference. |
| `sources/builtin.jq` | reference-to-replacement | DATA, TEXT, FLOW, PATH, IO stories | Reference definitions specify many builtin compositions. | Implement the generator core before these builtins. |
| `sources/jq.test` | test-kit-to-implementation | `jq` | Corpus supplies program, input, and expected output cases. | Stage unchanged and execute through the harness. |
| `sources/run_conformance.py` | test-kit-to-implementation | `jq` | Runner invokes `JQ -c program` and checks exit/output semantics. | Preserve the executable interface and scoped verification. |
| `sources/full_test.sh` | test-kit-to-implementation | `sources/run_conformance.py` | Full script checks executable presence and delegates the complete run. | Reserve for the terminal acceptance story and Sea Trial. |
| `sources/exclusions.txt` | test-kit-to-implementation | `sources/jq.test` | Exclusions identify module-loader cases by exact program text. | Apply skips through the supplied harness only. |
| `sources/INSTRUCTIONS.md` | instruction-to-test | all implementation and conformance stories | Build order, prohibitions, interface, and definition of done are explicit. | Treat as author intent and project guardrails. |
## Source Roles
| Path | Role | Plan disposition | Build disposition |
|---|---|---|---|
| `sources/INSTRUCTIONS.md` | author intent | compass | prompt-only |
| `sources/jq-manual.txt` | normative specification | context | stage |
| `sources/jq.test` | normative specification and conformance test suite | context | stage |
| `sources/parser.y` | normative specification | context | stage |
| `sources/lexer.l` | normative specification | context | stage |
| `sources/builtin.jq` | reference implementation | context | stage |
| `sources/run_conformance.py` | conformance harness | context | stage |
| `sources/full_test.sh` | conformance harness | context | stage |
| `sources/exclusions.txt` | conformance harness | context | stage |
## Planning Instructions
### Delivery Shape
Deliver a standalone executable Python jq interpreter. It parses a jq filter, evaluates it over JSON input as an ordered stream of values, and writes compact JSON outputs. The execution flow is lexer/parser, AST or equivalent intermediate representation, generator evaluator, builtin/function runtime, and CLI serialization. The staged conformance runner drives one process per corpus case; excluded module-loader cases are skipped by the supplied exclusion list.
### Story Realization Map
| Story IDs | Durable Blueprint scope | Evidence | Related files | Delivery kind |
|---|---|---|---|---|
| EXEC-001–003 | executable CLI and JSON process boundary | `sources/INSTRUCTIONS.md`, `sources/run_conformance.py` | `jq` | capability and acceptance contract |
| PARSE-001–004 | lexer, parser, syntax diagnostics | `sources/lexer.l`, `sources/parser.y`, `sources/jq.test` | `jq` | capability |
| CORE-001–004 | stream evaluator and runtime errors | `sources/INSTRUCTIONS.md`, `sources/jq-manual.txt` | `jq` | capability |
| VALUE-001–004 | value model, accessors, numeric behavior | `sources/jq-manual.txt`, `sources/jq.test` | `jq` | capability |
| FLOW-001–006 | operators and control constructs | `sources/builtin.jq`, `sources/parser.y`, `sources/jq.test` | `jq` | capability |
| FUNC-001–004 | bindings, functions, patterns | `sources/parser.y`, `sources/jq.test` | `jq` | capability |
| PATH-001–004 | paths and immutable updates | `sources/jq-manual.txt`, `sources/jq.test` | `jq` | capability |
| DATA-001–004 | collection and relational builtins | `sources/builtin.jq`, `sources/jq-manual.txt` | `jq` | capability |
| TEXT-001–004 | strings, formats, regex, dates | `sources/builtin.jq`, `sources/jq-manual.txt` | `jq` | capability |
| IO-001–003 | input, diagnostics, streaming | `sources/jq-manual.txt`, `sources/jq.test` | `jq` | capability |
| CONF-001–003 | staged assets, scoped runner use, terminal verification | `sources/INSTRUCTIONS.md`, `sources/run_conformance.py`, `sources/full_test.sh` | `sources/*` | test harness and acceptance contract |
### Test and Acceptance Strategy
Implementation stories use focused `sources/run_conformance.py --select` slices matching their construct. Parser stories also exercise the supplied `%%FAIL` cases. No intermediate story runs `full_test.sh` or the unscoped runner. `CONF-003` is the sole terminal full-suite story and declares `Suite: full`; it depends on all implementation stories and asserts only the full harness exit status. Sea Trial `st-001` proves the same complete corpus requirement.
### Sequencing and Dependencies
Build the executable boundary first, then lexer/parser, then generator evaluation and value semantics. Implement paths and assignment after accessors and generators. Add control flow and functions before higher-level builtins. Implement collection, text, regex, date, I/O, and streaming groups afterward. Stage all assets before acceptance execution. The terminal full-suite verification is last and depends on every implementation story. No external service or package dependency exists.
### Source Conflicts and Gaps
No unresolved cross-source conflicts or blockers were found. The fixed Python standard-library runtime, executable contract, complete-corpus gate, excluded module-loader cases, and forbidden third-party implementations are consistent across the supplied instructions, harness, corpus, manual, lexer, parser, and builtin reference.
## Analysis Notes
generated: 2026-08-22T00:00:00Z
blueprint: /mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint
Quality: Ready
blockers: 0
questions: 0
features: 10
stories: 42
stack: Python standard library
display_name: not proposed
short_description: not proposed
The project type is `cli`. The source-defined story breakdown is broad but remains below the 100-story blocker threshold. The 42-story decomposition follows the supplied implementation order and major manual/conformance domains.</pblock>
<pblock filename="SEA_TRIALS.md" role="project acceptance contract" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/SEA_TRIALS.md">
# Sea Trials: jq
## Policy
| Consequence | On FAIL | On INCONCLUSIVE |
|---|---|---|
| blocks | fail | attest |
| scores | score | score |
| attests | report | report |
## st-001: The supplied scoring script passes
Type: technical
Required: yes
Criterion: The completed interpreter shall make sh sources/full_test.sh exit zero; that script's exit status is the sole acceptance verdict.
Testability: deterministic
Consequence: blocks
Verification: proof
Command: ["sh", "sources/full_test.sh"]
Pattern: ubiquitous</pblock>
<pblock filename="STORY_GUIDANCE.json" role="governed story guidance" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/STORY_GUIDANCE.json">
{
"stories": [
{
"id": "EXEC-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"^(true|false|null|1)$"
],
"note": "Build Instructions: interface contract"
},
{
"id": "PARSE-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"^(true|false|null|1|\\.)$"
],
"note": "lexer.l"
},
{
"id": "PARSE-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"interpolation|@base64|@uri"
],
"note": "lexer.l and jq.test string/format cases"
},
{
"id": "PARSE-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"\\.|\\[|\\{|\\+|\\-|\\*|/|%"
],
"note": "parser.y expression grammar"
},
{
"id": "PARSE-004",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"%%FAIL|if |try |reduce |foreach |def | as |label |module|include"
],
"note": "parser.y declarations and control grammar"
},
{
"id": "CORE-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"\\.|,|\\[\\.\\]|range|empty"
],
"note": "Build Instructions: generator core"
},
{
"id": "CORE-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"\\||,|\\[|\\{"
],
"note": "jq-manual.txt generator semantics"
},
{
"id": "CORE-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"try|error|\\?"
],
"note": "jq-manual.txt error and optional semantics"
},
{
"id": "CORE-004",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"==|!=|<=|>=|<|>"
],
"note": "jq-manual.txt comparison and truthiness"
},
{
"id": "VALUE-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"nan|infinite|tojson|fromjson"
],
"note": "jq-manual.txt types and numeric values"
},
{
"id": "VALUE-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"\\.[A-Za-z]|\\[[-0-9]"
],
"note": "jq-manual.txt accessors"
},
{
"id": "VALUE-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"\\[.*:|\\.\\[\\]"
],
"note": "jq-manual.txt slices and iteration"
},
{
"id": "VALUE-004",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"length|type|sqrt|floor|tonumber"
],
"note": "jq-manual.txt types and numeric builtins"
},
{
"id": "FLOW-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"\\+|\\-|\\*|/|%"
],
"note": "jq-manual.txt builtin operators"
},
{
"id": "FLOW-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"and|or|not|//"
],
"note": "jq-manual.txt conditionals and comparisons"
},
{
"id": "FLOW-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"if |try |\\?"
],
"note": "jq-manual.txt conditionals and try-catch"
},
{
"id": "FLOW-004",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"label|break"
],
"note": "jq-manual.txt breaking out of control structures"
},
{
"id": "FLOW-005",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"reduce|foreach|limit|skip|nth|first|last"
],
"note": "jq-manual.txt advanced generators"
},
{
"id": "FLOW-006",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"while|until|recurse|repeat"
],
"note": "jq-manual.txt recursive generators"
},
{
"id": "FUNC-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
" as \\$|\\$[A-Za-z]"
],
"note": "jq-manual.txt variable binding"
},
{
"id": "FUNC-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"def .*\\("
],
"note": "jq-manual.txt defining functions"
},
{
"id": "FUNC-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"def "
],
"note": "jq-manual.txt function scoping and recursion"
},
{
"id": "FUNC-004",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"\\?//| as \\{"
],
"note": "jq-manual.txt destructuring alternatives"
},
{
"id": "PATH-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"path\\(|paths|pick\\("
],
"note": "jq-manual.txt paths"
},
{
"id": "PATH-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"getpath|setpath|delpaths"
],
"note": "jq-manual.txt path primitives"
},
{
"id": "PATH-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"=|\\|=|\\+="
],
"note": "jq-manual.txt assignment"
},
{
"id": "PATH-004",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"negative|NaN|depth|empty"
],
"note": "jq.test assignment edge cases"
},
{
"id": "DATA-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"map|flatten|transpose|combinations|walk"
],
"note": "builtin.jq collection utilities"
},
{
"id": "DATA-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"sort|group_by|unique|min|max"
],
"note": "jq-manual.txt collection ordering"
},
{
"id": "DATA-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"keys|has\\(|contains|inside|to_entries|from_entries"
],
"note": "jq-manual.txt object and containment builtins"
},
{
"id": "DATA-004",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"indices|index\\(|rindex|bsearch|any|all|IN\\("
],
"note": "builtin.jq generic iterator and membership utilities"
},
{
"id": "TEXT-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"split|join|trim|ascii_|explode|implode|startswith|endswith"
],
"note": "jq-manual.txt string builtins"
},
{
"id": "TEXT-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"@text|@json|@html|@uri|@csv|@tsv|@sh|@base64"
],
"note": "jq-manual.txt format strings and escaping"
},
{
"id": "TEXT-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"test\\(|match\\(|capture\\(|scan\\(|sub\\(|gsub\\("
],
"note": "jq-manual.txt regular expressions"
},
{
"id": "TEXT-004",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"date|strftime|strptime|gmtime|mktime"
],
"note": "jq-manual.txt dates"
},
{
"id": "IO-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"input|inputs"
],
"note": "jq-manual.txt I/O"
},
{
"id": "IO-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"debug|stderr|halt_error"
],
"note": "jq-manual.txt diagnostics"
},
{
"id": "IO-003",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"tostream|fromstream|truncate_stream"
],
"note": "jq-manual.txt streaming"
},
{
"id": "CONF-001",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--list"
],
"note": "Build Instructions: source roles and staged assets"
},
{
"id": "CONF-002",
"provenance": "plan",
"gate": [
"python3",
"sources/run_conformance.py",
"--select",
"reduce"
],
"note": "Build Instructions: scoped verification"
},
{
"id": "CONF-003",
"provenance": "plan",
"gate": [
"sh",
"sources/full_test.sh"
],
"note": "Sea Trials and definition of done"
}
]
}</pblock>
<pblock filename="ACCEPTANCE.json" role="governed acceptance contract" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/ACCEPTANCE.json">
{
"full": [
"sh",
"sources/full_test.sh"
]
}</pblock>
<pblock filename="MANIFEST_CONTRACT.md" role="contract" path="/mnt/c/Users/barlo/projects/drydock/prompts/MANIFEST_CONTRACT.md" guidance="MANIFEST output contract. Follow it exactly.">
---
name: Manifest Contract
description: Contract governing the format, story types, field semantics, lifecycle states, block grouping, and execution rules for `MANIFEST.md` — the single generated executable build plan for a Drydock Target.
version: 20260801 V14
---
## Overview
`MANIFEST.md` is the single generated execution view of the Blueprint. It determines build order,
selects required context, keeps work within useful context limits, identifies stale work, and
preserves unaffected accepted work. It is not a second product definition.
**Location:** `$DRYDOCK_WORKSPACE/targets/<Target>/MANIFEST.md`
The Manifest manages the full product lifecycle:
- specifications for individual components can be changed, resulting in context-minimized
incremental builds
- new files (such as change tickets) can be discovered and applied
---
## Plan Header
```markdown
# MANIFEST: {ProjectName}
updated: 2026-06-08T12:00:00
plan_hash: abc123456789
applied_specs: |
DATABASE.md sha256=<content_sha256> commit=<file_commit_sha> applied_by=foundation applied_at=2026-06-26T14:22:00Z
planning_feedback: |
decision-0123456789abcdef applied FEATURE-CATALOG.md
decision-fedcba9876543210 retained
```
Build execution evidence lives in the execution log. The Manifest preamble carries build-state
provenance required to detect stale previously applied Blueprint Specifications. `applied_specs`
records one line per Blueprint Specification file applied by a successful story. The path
is relative to `blueprint/`. `sha256` is the authoritative dirty signal. `commit` is the latest git
commit that touched that file, or `-` when unavailable. `applied_by` identifies the story
that last applied the file. `applied_at` is the UTC application timestamp.
---
## Story Types
The Manifest is a list of stories. A `type` field is the only variation.
| Type | Contains | Runs |
|---|---|---|
| `foundational` | Foundation and scaffolding | Early; work depends on it |
| `service` | Everything that does work | Reorderable |
| `feature` | Acceptance criteria plus assembly and intent; no implementation instructions | After its members |
Foundational work is structure and scaffolding. Standing up S3 and proving the connection is
architecture. Everything S3 subsequently does is a service. Everything that is not architecture is
a service, and services are reorderable because they carry no structural debt. Much of what source
material labels architecture is service work: the web server and the database are foundation; a
voice service interpreter is a service wearing an architecture filename.
Foundation status derives from the dependency graph, not from a filename prefix. The rule is
*build the foundation that is needed*, not *build all foundation first*.
There is no fourth type. A "foundational service" — voice-to-text, for example — is foundational to
whatever depends on it, which the edges already state more precisely than a label could.
`spike` is not a story type. Research questions are handled by questionnaires before Plan and by the
owning story's `## Questions` section after. `ac` is not a story type: Programmatic Acceptance is
verification the build runs to prove a story is complete. A story is not "built and failed" — it is
built or it is not, so acceptance is a field the story owns and passing is part of the story's own
state transition.
### Feature is an assembly story
A feature is a story that depends on its member stories, carries acceptance criteria, and carries
assembly and intent instructions instead of implementation instructions. Same node, same execution
path, different content shape. When its member stories complete, the feature story runs and is made
to pass like any other story, so integration testing is a real build step rather than an implicit
hope. A feature story is preferably placed in the same block as its members.
### Story
```markdown
## story N: {Name}
id: foundation
summary: One-line description.
type: foundational
kind: capability
phase: 1
block: 1
implements: ARCHITECTURE.md
covers: CATALOG-001
accepts: st-001
context: DATABASE.md
stack: common.md, python.md, fastapi.md
stack_mode: builder
provides: GET /health
consumes:
instructions: |
Stand up the application factory and health check.
acceptance: yes
depends:
state: pending
```
**Field reference:**
| Field | Required | Authored by | Description |
|-------|----------|-------------|-------------|
| `id` | Yes | Model | Stable unique slug within the Manifest |
| `summary` | Yes | Model | One-line description |
| `origin` | No | `drydock refit` | Provenance of a story authored from a source change, as `<source>@<commit>`. Absent on stories authored by `plan`. |
| `created` | No | `drydock refit` | ISO date the story was appended to the graph. |
| `type` | Yes | Model | `foundational` \| `service` \| `feature` |
| `kind` | Yes | Model | Delivery kind: `capability` \| `integration` \| `migration` \| `test harness` |
| `phase` | Yes | Model | Commander build sequencing; see below |
| `block` | Generated | Drydock | Context-optimization group; computed, never authored |
| `implements` | Yes | Model | The single governed specification this story builds |
| `covers` | No | Model | `ANALYSIS.md` Story IDs this story delivers. Every analyzed Story ID is named by exactly one story, whatever its `type`; a story with no analyzed counterpart omits the field |
| `accepts` | No | Model | `SEA_TRIALS.md` IDs this story implements |
| `context` | No | Model | Read-only support context files. Never a Compass file |
| `stack` | No | Model | Rigging stack files this story builds with |
| `stack_mode` | Generated | Drydock | `builder` \| `consumer`; computed from first use in build order |
| `provides` | No | Model | Routes, commands, symbols, datasets, queues, or events this story defines |
| `consumes` | No | Model | Interface points this story calls |
| `rules` | No | Model | Rigging rules files to inject |
| `copy` | No | Model | `source -> destination` file copies applied before build |
| `instructions` | Yes | Model | Freeform build instructions. A `feature` carries assembly and intent, not implementation |
| `acceptance` | Yes | Model | `yes` when the story has real acceptance to honor |
| `depends` | No | Model | Story ids that must be `closed/verified` first |
| `state` | Yes | Drydock | Current block state |
| `evidence` | No | Drydock | Path to the evidence file written after execution |
| `scope` | No | Model | `blueprint` \| `target` \| `both` — what this story changes |
Stories and governed specifications are one-to-one: every story implements exactly one
specification, and every specification is implemented by exactly one story. The story is the atomic
build primitive.
**Story sizing.** A story is a normal Agile story: 1 to 5 story points. Never a half point — that is
a task, folded into the story it serves. Never twelve — that is split. A story does one thing
completely, carries test criteria, and is releasable on its own; a task is not releasable and is
therefore not a story. A story has no token dimension. Token cost is measured against the block a
story is built in, never against the story. Story count is not capped: it is an output of correct
decomposition, not a target.
### Authorship versus verification
The model authors relationships, the actual topology (the story dependency graph), the high-level
topology (phases), and Programmatic Acceptance. Drydock verifies all of it, groups blocks, orders
the work, and serializes the Manifest.
The model never sorts, never checks its own consistency, and never reasons about a position in an
order it has not computed. It states what each story requires and provides; Drydock does the rest.
Contradictions become a deterministic error with a precise message instead of a shape failure.
`drydock plan create` therefore does not emit this file. It emits a flat `TOPOLOGY.md` declaration
carrying the Model-authored fields below — one `## story <id>` heading per governed specification,
no ordering, no `block:`, no `stack_mode:`, no `state:` — and Drydock serializes `MANIFEST.md` from
it. The field semantics in this contract govern both forms.
**Two-topology check.** The high-level and actual topologies must agree: a story in phase 2 cannot
depend on a story in phase 3.
### Phase
`Phase` is Commander instruction on how to build: *build Feature X, then Feature Y*. It is not a
layer chain. The layer stack repeats inside each phase rather than running once across the project —
foundational / database / service / ui, then service / ui, then foundational / service / service /
ui. Commander ordering direction is input the model weighs, not an override applied afterward.
`Phase` describes when a file is built, not the file, so it lives in the Manifest and never in a
Blueprint header.
### Blocks
A **block** is a set of stories optimized for context: sized to amortize fixed stack-file cost
across one build run, never crossing stacks. Blocks are an optimization output, not a taxonomy. UI
stories group together whether or not they belong to the same Agile feature. Context economy comes
from blocks, not from feature grouping.
Blocks are ephemeral, Manifest-only, regenerated every run, and computed by Drydock:
- **Hard:** one topology type per block; never cross a phase boundary; never violate the edges
- **Objective:** amortize stack-file cost across the most stories that still fit one build pass
The mechanism behind the no-cross-stack guardrail is stack creep from Rigging. Mixing topology types
in one block forces every stack file each type needs into the block, so it pays for context neither
half uses and the build agent reads instructions for work it is not doing. This is the reason story
types exist: they are the block-partition key.
### Builder and consumer mode
The model authors the foundational story that stands a stack up. Drydock assigns the
builder/consumer flag from first use in the computed order: by definition the first story using a
stack is the builder and later ones are consumers. Ordering is build-order-global, as compact
substitution already is — not per-block, not phase-based. A builder story receives the full stack
file; a consumer story receives the interface view.
If the model assigned the flag it would be asserting a position in an order it has not computed.
Disagreement is a defect signal, not a tie to break: if the first user of a stack is not a
`foundational` story, an edge or a foundational story is missing and Drydock reports it. Ambiguity
defaults to builder, because consumer-when-it-should-be-builder starves the build agent while
builder-when-it-should-be-consumer merely costs tokens.
---
## Acceptance
Acceptance lives in one place per audience:
- **Programmatic Acceptance** — executable assertions carrying pass/fail state. Lives in
`MANIFEST.md`. Not human-readable, not human-editable, regenerated wholly by every plan run.
- **User Acceptance** — human-readable intent. Lives in the Blueprint specification.
The discriminator for every other fact is the same question: **does the fact describe the artifact
or the schedule?**
| Fact | Home | Why |
|---|---|---|
| `Provides`, `Consumes`, `Depends On` | Blueprint header | Describe the file — what it offers and requires |
| Story `type` | Manifest | Computed, machine-focused |
| `Phase` | Manifest | Describes when the file is built, not the file |
| Programmatic Acceptance | Manifest | Machine-focused; nobody should hand-edit it |
| User Acceptance, `## Questions` | Blueprint | Human intent |
Durability is not a discriminator: the Blueprint does not survive a replan. Only the `## Questions`
section, harvested deterministically beforehand, survives.
---
## Block States
Every story uses the same four states:
| State | Meaning |
|-------|---------|
| `pending` | Not run yet |
| `implemented` | Work done, waiting to be accepted |
| `closed/verified` | Passed or accepted |
| `closed/failed` | Failed or rejected |
---
## Execution Rules
A story runs only when everything in `depends:` is `closed/verified`.
Programmatic Acceptance runs after the story build and is part of the story's own state
transition: a story that fails its acceptance becomes `closed/failed` and blocks dependent work.
There is no separate acceptance node with independent state.
A `feature` story runs after its member stories close. Its assembly and intent instructions are
made to pass like any other story's, which is what turns integration testing into a real build step
covering the seams between stories where multi-story builds actually break.
`closed/failed` is not terminal. The product owner reopens failed work from the QuarterDeck —
revising instructions, acceptance, or scope interactively — and the decision writer returns it to
`pending` with the revision recorded. Recovery never requires hand-editing the Manifest.
An open `Blocking` Blueprint question projects the story state as `blocked/questions`. That story
and its dependents are unavailable, while independent frontier stories remain buildable. Open `Low`
and `Material` decisions remain visible without gating.
`User Acceptance` entries are Commander review signals and do not block ordinary downstream build
unless modeled as explicit dependencies.
---
## Sea Trials Traceability
`accepts:` lists stable project-acceptance IDs from `SEA_TRIALS.md` that the story implements.
Every required technical or behavioral Sea Trial is referenced by at least one story or by a
Blueprint Programmatic Acceptance proof. Unknown IDs are invalid.
## Plan State Writer
The **decision writer** is the only mutator of Manifest block state. It is invoked by:
- the QuarterDeck review controls (approve, revise, reject, add defect on individual blocks)
- the `drydock build` engine (state transitions during execution)
Review decisions written in the QuarterDeck write back to `MANIFEST.md` through the same
decision writer used by the CLI.
---
## Relationship to Blueprint
The Manifest is generated from the Blueprint; it is not a second product definition. `drydock plan
create` reads all Blueprint inputs and writes `MANIFEST.md` — the single work graph carrying build
order, grouping, and per-step prompt-assembly fields. It regenerates after each planning cycle.
The Blueprint remains the source of truth for what the project is and must do. The Manifest is
the source of truth for build state. The QuarterDeck renders Manifest state and records decisions
through the plan writer — the console can be deleted and regenerated at any time.</pblock>
<pblock filename="BLUEPRINTS_CONTRACT.md" role="contract" path="/mnt/c/Users/barlo/projects/drydock/prompts/BLUEPRINTS_CONTRACT.md" guidance="Blueprint output contract. Follow it exactly.">
---
name: Blueprints Contract
description: Contract governing the layout, file types, header format, and dependency conventions for Drydock Blueprint files.
version: 20260822 V16
---
## Overview
A **Blueprint** is the complete Typed Specification for one project. It lives at
`$DRYDOCK_WORKSPACE/targets/<Target>/blueprint/` and contains all human-authored and
process-created specification files. The Blueprint is the single source of truth for what the
project is, what it must do, and how it is built.
---
## Specification File Types
| File | Purpose | Required |
|------|---------|----------|
| `METADATA.md` | Project identity: name, display_name, short_description, status, stack, code_root | Yes |
| `COMPASS.md` | Project guidance: intent, constraints, and guardrails | Yes |
| `ARCHITECTURE.md` | Modules, routes, boundaries, interfaces, technical decisions | Yes |
| `README.md` | One-line description and `## Intent` section | Yes |
| `DATABASE.md` | Persistence contract: access patterns, typed interfaces, all stores, schemas, migrations | If has persistent state |
| `UI-GENERAL.md` | Shared UI patterns across screens | If has UI |
| `SCREEN-{Name}.md` | Per-screen: route, layout, interactions, programmatic and user acceptance | If has UI |
| `FEATURE-{Name}.md` | Per-feature: purpose, status, trigger, sequence, routes, reads, writes, acceptance, guardrails | As needed |
| `ARCHITECTURE_compact.md` | Compact architecture derivative for downstream build-step injection | Optional |
| `DATABASE_compact.md` | Compact persistence derivative for downstream build-step injection | Optional |
| `HOMEPAGE.md` | Portfolio homepage: branding, contact, bio | If publishes a portfolio |
| `HOMEPAGE-PUBLISHER.md` | Template-based homepage publishing configuration | If publishes a portfolio |
| `IDEAS.md` | Feature ideas and backlog — no typed header required | No |
| `*-AC.md` / `AC-*.md` / `*-AC-*.md` | Acceptance criteria — any file where `AC` is a whole word in the filename | As needed |
| `changes/TICKET-NNN-{Name}.md` | Post-baseline change, defect, or spike request | As needed |
Every authored Specification file ends with `## Programmatic Acceptance`, `## User Acceptance`,
and `## Guardrails`. Use `- None.` when no entries apply. Planning disclosures and Commander
responses are records in the target's `DECISIONS.json`.
`ARCHITECTURE_compact.md` is a compact derivative of `ARCHITECTURE.md` produced by
`drydock rigging compact`. Drydock uses filename-selected compaction algorithms rather than
phase-aware compact variants.
`DATABASE_compact.md` is a compact derivative of `DATABASE.md` produced by `drydock rigging compact`.
---
## Specification File Header Format
Every authored Specification file except `METADATA.md` and `README.md` must begin with a typed
header. Operational and generated files (`IDEAS.md`, build plans, analysis outputs, and AC files)
are not authored Specification files.
```markdown
# {FileType}: {ObjectName}
| Field | Value |
|-------------|-------|
| Version | YYYYMMDD V1 |
| Description | One sentence summary. |
| Depends On | FEATURE-SERVICE-CATALOG.md, UI-GENERAL.md |
| Provides | GET /welcome, GET /welcome/summary |
| Phase | 2 |
```
**FileType values:** `COMPASS`, `SCREEN`, `FEATURE`, `DATABASE`, `UI-GENERAL`, `ARCHITECTURE`,
`HOMEPAGE`, `CHANGE`
**ObjectName:** Human-readable name matching the file subject (e.g., `Welcome Summary`,
`Service Catalog`).
**Fields:**
| Field | Set By | Required | Description |
|-------|--------|----------|-------------|
| `Version` | Author | Yes | Date + increment: `YYYYMMDD V1`. Every agent write must set this to the current date with the next increment. If the existing version is already today's date, increment the number. Never carry forward a stale date. |
| `Description` | Author | Yes | One sentence |
| `Depends On` | `drydock plan create` | No | Filenames this file requires to exist before build |
| `Provides` | `drydock plan create` | No | HTTP routes or interfaces this file exposes |
| `Phase` | `drydock plan create` | No | Build phase hint (integer); tooling may override |
**Additional optional fields for SCREEN files:**
| Field | Required | Description |
|-------|----------|-------------|
| `Route` | No | The URL this screen is served at |
| `Parent` | No | Parent menu item or `—` |
| `Main Menu` | No | Menu label and position |
| `Sub Menu` | No | Submenu label and position |
| `Tab Order` | No | Tab index within parent, or `—` |
`Depends On` and `Provides` are written by `drydock plan create` — do not edit manually.
`Phase` is written by `drydock plan create` — do not edit manually unless overriding.
**Additional required fields for CHANGE files (`changes/TICKET-NNN-{Name}.md`):**
| Field | Set By | Required | Description |
|-------|--------|----------|-------------|
| `Amends` | Author / `drydock refit` | Yes | The parent Blueprint spec this ticket modifies (e.g. `FEATURE-Copy.md`). `drydock refit` reads this field to resolve dependency inheritance and inject parent context. |
| `Depends On` | `drydock refit` | Yes | Copied from the parent spec's `Depends On` set plus the parent spec filename itself. Do not edit manually. |
| `Scope` | Author / `drydock refit --sources` | Yes | `additive` or `amending`. Governs what the ticket supersedes. |
| `Created` | `drydock refit` | Yes | ISO date the ticket was authored. |
| `Origin` | `drydock refit --sources` | No | The source version this ticket came from, as `<source>@<commit>`. Absent on hand-authored tickets. |
| `Stories` | `drydock refit --sources` | No | The Manifest story ids this ticket owns. When present, `drydock refit` emits exactly these ids and never invents new ones. |
**Scope semantics.** A ticket declares its authority over its parent in one sentence directly
below the header table.
- `additive` — the ticket adds behavior. It supersedes nothing, and every assertion in the parent
Blueprint remains in force. Sentence: *"This ticket is additive. It supersedes nothing; every
assertion in `<parent>` remains in force."*
- `amending` — the ticket alters behavior already specified. It supersedes only the sections
listed under `## Amended Sections`, each of which must exist as a heading in the parent.
Sentence: *"This ticket amends `<parent>`. It supersedes only the sections named under
`## Amended Sections`; every other assertion in `<parent>` remains in force."*
An additive ticket must never claim authority over its whole parent: a single added requirement
would otherwise supersede assertions it does not mention and that have already been proven.
---
## Common Authored Specification Sections
Plan and Build disclosures use the existing `DECISIONS.json` schema. `severity: blocking` is the
only decision gate and blocks only the attached story while its Commander response is absent.
Analyze questionnaire answers are converted to `origin: analyze-questionnaire` records. Commander
responses remain in the same records across replans.
Every authored Specification file ends with these sections, using `- None.` when no entries apply:
```markdown
## Programmatic Acceptance
- None.
## User Acceptance
- None.
## Guardrails
- None.
```
`Programmatic Acceptance` contains executable Python assertion snippets. Each check is one
explicitly delimited block that can run from the build directory after the story implementing the
file completes:
```
=== AC {check-id} ===
Intent: One sentence stating what the check proves.
Suite: scoped
Requires: executable=python3; scope=test
<Python source, verbatim, to the end marker>
=== END AC {check-id} ===
```
The delimiters are the whole format. The id lives in the opening marker, so it is never inferred
from a nearby heading. Declarations are the `Key: value` lines at the top of the block, ending at
the first blank line; `Intent:` is required and the rest are optional. Everything after that blank
line is the proof body, taken character for character to the matching end marker.
Nothing inside the body can move a boundary. A Markdown fence, a `##` line, a `###` line, or a
`Requires:` line inside a string is ordinary content — which matters, because a target that
processes markup will legitimately embed all of them in its proof. Write the body as plain Python;
do not wrap it in a fence.
Write `=== END AC {check-id} ===` for every `=== AC {check-id} ===` you open, with the same id.
The end marker is not optional and the next opening marker does not stand in for it. Where the
boundary is decidable Drydock inserts the missing marker and reports having done so; where it is
not, planning stops.
An end marker naming a different id, a stray end marker, and a duplicate id are hard errors that
stop planning. None of them degrade into a criterion that silently stops gating.
A backslash in the proof body belongs in a raw string or is doubled. Write `r"\d+"`, `"\\("`, or
`r"\("` — never a bare `"\("`. A bare backslash before a character Python does not recognize as
an escape is not the escape you wrote: it survives today only by a rule scheduled to become a
hard error, and it costs the criterion its binding status. This applies to every proof that
embeds a regular expression, a Windows path, or a target language's own escape syntax.
### The oracle rule
> **Act on the system. Read the state back. Compare to expected.**
Arrange–Act–Assert, where the assertion reads *state*, never text a process printed.
| Oracle | Verdict |
|---|---|
| Return value, parsed JSON, status code, DB row, file contents read back, exit status | **Correct** |
| Substring of captured stdout/stderr, test-runner tally text, log lines | **Forbidden** |
A state oracle cannot pass against a stub and cannot fail because a runner printed the word
"warning". Almost every acceptance defect observed in practice has the same shape: the oracle was
a string in captured output.
### The expected value must be one you could not get wrong
Reading state back is half the rule. The other half is what you compare it *to*.
> **Never type an expected value twice. Bind it to a name and use the name on both sides.**
You are authoring this criterion before the code exists, so a hand-typed expectation is a
prediction about bytes you have not seen. When the prediction is wrong the criterion fails against
a correct implementation, and nothing downstream can tell that from a real defect. This is the
single largest source of wasted build budget on record.
| Expected value | Verdict |
|---|---|
| A name bound to the value the criterion supplied as input | **Correct** |
| A status code, exit status, or count | **Correct** |
| A contract token read off a declared interface — `"integer"`, `"application/json"`, `"POST"` | **Correct** |
| A staged suite's exit status | **Correct** |
| A string literal you typed out as the expected result | **Forbidden** |
The forbidden row is judged mechanically: a string expectation carrying anything escapable —
whitespace, a backslash, a quote, a newline, a non-ASCII character — that the criterion did not
also supply as input. A criterion that breaks the rule still runs and is still reported, but it
settles `DISPUTED` and gates nothing, so it buys the story no coverage at all.
The case this comes from. Wrong:
```
source = 'basic = "line\\nvalue"\nraw = \'C:\\\\Users\\\\nodejs\'\n'
result = subprocess.run(["./toml-decoder"], input=source, capture_output=True, text=True)
decoded = json.loads(result.stdout)
assert decoded["raw"]["value"] == r"C:\Users\nodejs" # re-typed, and wrong
```
A TOML literal string preserves its backslashes verbatim, so the decoder returned the doubled
form and the expectation was wrong. Right:
```
raw = "C:\\Users\\nodejs"
source = f"raw = '{raw}'\n"
result = subprocess.run(["./toml-decoder"], input=source, capture_output=True, text=True)
decoded = json.loads(result.stdout)
assert decoded["raw"]["value"] == raw # one spelling, cannot disagree
```
The same rule applies when the re-typed value is not a string literal but an independently
reconstructed expression — a rebuilt path, URL, or timestamp compared against one the code under
test computes itself. Two spellings of "the same" value can disagree exactly where a normalization
step is involved (`.resolve()` against a relative join, a trailing slash, case folding), and the
criterion has no way to know which spelling the implementation is entitled to produce. Read the
value back from what the code exposes; do not reconstruct a second copy to compare it to.
Wrong:
```
from pathlib import Path
sources = Path("sources")
import run_conformance
assert run_conformance.CORPUS == sources / "jq.test" # rebuilt, and not the same path shape
```
`run_conformance.CORPUS` is `Path(__file__).resolve().parent / "jq.test"` — absolute, because the
module resolves its own location. `sources / "jq.test"` is relative. Nothing the implementation
does can make these equal; the criterion is unsatisfiable regardless of correctness. Right:
```
from pathlib import Path
sources = Path("sources")
import run_conformance
assert run_conformance.CORPUS == (sources / "jq.test").resolve()
```
or, when the criterion only needs to know the module points at the right file, assert what it
actually claims rather than reconstructing a value to compare:
```
assert run_conformance.CORPUS.samefile(sources / "jq.test")
```
When a transform's output genuinely cannot be derived from its input — a renderer turning `# h`
into `<h1>h</h1>` — do not hand-write the expectation at all. Bind the criterion to the
authoritative suite that defines correctness for that transform. Where no such suite exists, put
the case in the project's own test suite, where the implementer writes it against real output,
rather than predicting it here.
### Two test destinations
A project carries tests in two places, and they are not the same artifact with different names.
| | **Story AC** — `=== AC <id> ===` | **The project's own test suite** |
|---|---|---|
| Job | gate the block | know the code works |
| Count | few | unbounded |
| Authored | here, by planning, **before the code exists** | by the build agent, **alongside the code** |
| Oracle discipline | the rules above, without exception | full latitude — expectations are observed, not predicted |
| Effect | binding: it decides whether the block closes | diagnostic: it guides repair, and its command is what a project criterion runs |
| Runs | at its block | continuously, cumulatively |
The split is not a matter of taste. Every expected value written here is a *prediction* about
bytes that do not exist yet, and a wrong prediction fails a correct implementation — which is why
the oracle rule and the no-re-typed-literal rule are absolute in this file. A test written beside
the finished code compares against output its author has actually seen, so the same assertion that
is hazardous here is safe there.
So this is *more* testing, not less. Exhaustive coverage belongs to the project's suite, which has
no ceiling. An AC block is permanently constrained by having to survive as a gate, so author few
and author them bulletproof. Coverage is never demonstrated by the number of AC blocks a story
carries; it is demonstrated by the suite, and it is graded at the project level through the Sea
Trial that runs that suite.
**Where an authoritative suite exists, it is the coverage.** A conformance corpus staged into
`sources/` defines correctness for the surface it covers. Bind one criterion to it and do not
restate its cases in either destination — a restated case adds no coverage and adds one more
expectation that can be wrong.
**The terminal story is the last story in the build order** — the one on which every other story
is a transitive dependency and after which no further story runs. It is decided by position in the
graph, never by name, type, or kind. A story is not terminal because it is called "verify", because
its `kind` is a test harness, or because it stages the test assets: staging the corpus is
foundational work that runs first, and running the corpus is terminal work that runs last. When a
plan contains several verification stories, exactly one of them is terminal and it is the one every
other story precedes. Identify it by resolving `depends` before writing any suite criterion.
**Only the terminal story runs the whole suite.** No intermediate story's acceptance invokes the
runner unscoped. A partial capability fails most of an authoritative corpus by construction, so an
unscoped mid-build run reports the schedule rather than a defect — and it is slow in exact
proportion to how incomplete the code is, because unimplemented cases exhaust the runner's per-case
timeout instead of returning. It costs most at the point in the build where it teaches least, and a
build agent that starts one mid-story typically abandons it and reports the suite as hung.
**An intermediate story runs its own slice, and the slice executes.** Scoped to the cases that
story implements, the run is neither slow nor red by construction: those are exactly the cases its
code is supposed to pass, so the result is a verdict about the story rather than a report on the
schedule. This is what makes build progress visible — the corpus goes green in the order the plan
builds it, and a regression in an earlier story is caught by the later story that re-runs it.
Executing is the whole point, so:
- The slice **runs cases**. A criterion that invokes the runner's list or dry-run mode executes
nothing, passes before the story's code exists, and proves only that the runner starts. Such a
criterion is a defect: it is green from the first build call to the last and steers no repair.
- The slice is **selected by the story's capability**, using the runner's own scoping flag — not by
case count, not at random, and never by a selector that silently pulls in cases belonging to
unbuilt stories. Size and inspect each selector with the runner's list mode **while planning**;
that is where list mode belongs, not in a criterion.
- Every slice invocation supplies each environment variable the runner declares required.
**Together the slices cover the corpus.** Every case an authoritative suite contains belongs to
some story's slice. A case no intermediate slice reaches is first executed by the terminal gate,
where a failure arrives with the whole build already spent and no story to attribute it to.
Overlap between slices is expected and costs nothing — a case exercised by two capabilities
legitimately belongs to both — but a gap is a story whose work no one checked.
**A story that only stages the suite asserts staging.** Where a story's obligation is that the
corpus parses, the exclusion list applies, and the runner starts — and it implements none of the
behavior under test — its criterion invokes the runner's list or dry-run mode and asserts the
runner exits `0` and reports the expected count. This is the one criterion for which executing
nothing is correct, because there is nothing of the product to execute yet. Leaving such a story
with no criterion at all is a defect: it produces a story that cannot be verified and a build block
that closes advisory.
If an imported instruction states where the suite may run, that statement governs.
### What a criterion is worth
Every criterion you write lands in one of four tiers. The tier is decided by how the criterion is
written, not by how it is labelled, and it decides what the criterion can do:
| Tier | What it is | What it does |
|---|---|---|
| **BLOCKING** | a Commander-governed gate, or a criterion bound to a staged authoritative suite | fails the block |
| **CONSULTATIVE** | a criterion whose expected value could not have been invented — a status code, an exit status, a value the criterion itself supplied as input | drives repair; unattended, it marks the block implemented-but-unverified rather than stalling the run |
| **ADVISORY** | a criterion that re-types an expected literal | runs, is reported `DISPUTED`, **gates nothing** |
| **VOID** | malformed: does not compile, or an unclosed container | not a criterion; recorded as a decision and gates nothing |
Aim deliberately. A hand-typed expectation does not merely risk being wrong — it demotes the
criterion to ADVISORY, so the story it was written to protect ends up with no gate at all. Binding
the value to a name is what buys the criterion its authority back.
None of these tiers reaches the release verdict. Story AC decides whether an increment was built;
project acceptance is decided by Sea Trials alone.
### Authoring patterns
Patterns **1, 4, 6, 9, and 10** are the discipline of a gate and govern what you write here.
Patterns **2, 3, 5, 7, and 8** are the discipline of a test suite: state them as expectations on
the project's own suite, which the build agent grows beside the code, rather than enumerating them
into AC blocks.
**1 — Round trip (the default form).** For anything that stores, mutates, or removes state:
```
create → read back → assert present, with expected field values
update → read back → assert changed, and only the intended fields changed
delete → read back → assert absent
```
The read-back is a *separate call through the public interface*, not an inspection of the object
returned by the write. A write that returns a plausible object while persisting nothing must fail.
**2 — Exercise every callable workflow.** *Suite pattern.* One test per public entry point, per
verb. Coverage is enumerated from the interface, not sampled: every HTTP route × every method it
declares including declared error paths; every CLI subcommand and every flag that changes
behavior; every exported library function. This belongs to the project's suite. Here, name the
routes a SCREEN provides — that gate is real — and leave the enumeration to the suite. Where a
staged authoritative suite already covers the surface, it is the coverage.
**3 — Idempotence.** *Suite pattern.* Where a verb claims idempotence (PUT, DELETE), apply it twice and assert the
second is a no-op — same resulting state, and the declared status for a repeat. Where a verb is not
idempotent (POST), apply twice and assert the declared behavior: two resources, or the declared
conflict. Prefer idempotent verbs where the semantics allow; the assertion is stronger.
**4 — Negative paths assert the contract, not the message.** Invalid input asserts the declared
failure signal — status code, exception type, exit status — never the wording of an error message.
Message text is prose and belongs to no contract.
**5 — Boundaries.** *Suite pattern.* Empty collection, exactly one, many. Absent optional fields.
Declared maxima. This is where a plausible-looking implementation actually breaks — and where a
predicted expectation is most likely to be wrong, which is why the cases belong beside the code
rather than here. Where a staged authoritative suite covers the surface, it is the coverage.
**6 — RED before GREEN.** The assertion must fail against the pre-implementation tree and pass
after. A check that passes against a stub is not a check.
**7 — Isolation and determinism.** *Suite pattern, and it applies here too.* Each test arranges its own data and does not depend on another
test's residue or on ordering. No wall-clock dependence, no third-party network, no unseeded
randomness, no sleep-based timing. Fresh store per test, or explicit teardown.
**8 — One behavior per test, named for the behavior.** *Suite pattern.* A failure should be
diagnosable from the test's name alone.
**9 — Subprocess discipline.** Where a check must shell out, **exit status is the verdict**. A
substring check beside an exit-status assertion is redundant at best and a false-positive generator
at worst. Never assert that a literal is absent from captured output.
**10 — In-language tooling.** A check is written in the project's own language and uses that
language's libraries — Python check, Python libraries; Go check, Go libraries. An in-language HTTP
client yields a status code and a parsed body, which is state. `curl` yields stdout, which is text
to scrape. Pattern 10 and the oracle rule are the same rule seen twice.
### Declaring external tooling
Reaching for an external executable is the exception, not the norm, and `curl` in particular will
not work in every environment. When a check genuinely needs one, the tool belongs in the project's
Rigging or `TECHNOLOGY_STACK.md`, declared once by the Commander and true for every check in the
project. A per-check declaration is also accepted and is recorded as a report:
```markdown
Requires: python-package=httpx; scope=test
Requires: executable=node; scope=test
```
Kinds are `python-package` and `executable`; scopes are `runtime` and `test`. Framework test
clients include their transport dependencies. `Requires:` metadata is not acceptance intent, and
a missing declaration never fails planning — a tool that is present and undeclared works fine.
A declared tool that is *absent* when the check runs reports UNVERIFIED, not FAIL: the check never
reached the code under test, so it says nothing about the build.
### Satisfiability
Every assertion must be satisfiable by a correct implementation. An expectation no implementation
can meet is a defect, not a red baseline. Escaping is the usual source of one: inside a raw
literal, `\n` and `\r` are a backslash followed by a letter, not a control character, so
`r"text\n"` asserts against six characters ending in a literal backslash. Binding the value to a
name and using it on both sides removes the question entirely, which is why that is the rule.
### Runnability
**Subprocess mode.** Match the mode to `input=`. Text input declares `text=True` or `encoding=...`;
binary input uses a bytes-like value and does not declare `text`, `encoding`, `errors`, or
`universal_newlines`. A mismatch raises `TypeError` before the program under test starts, which
reports UNVERIFIED — the criterion buys the story nothing. Write:
```
payload = "one line\n"
result = subprocess.run(["./program"], input=payload, capture_output=True, text=True)
assert result.returncode == 0
```
For a binary or invalid-encoding criterion, write:
```
result = subprocess.run(["./program"], input=b"\xff", capture_output=True)
assert result.returncode != 0
```
**ASCII test data.** Acceptance data is ASCII. Do not invent an encoding requirement: characters
outside ASCII test a property the specification never stated, and a criterion that fails on them
fails the build for something nobody asked the product to do. When the imported specification does
state an encoding requirement, the criterion says so and may then use that encoding:
```
=== AC runtime-utf8 ===
Intent: The executable round-trips UTF-8 source, per INSTRUCTIONS.md.
Encoding: utf-8
source = "café\n"
result = subprocess.run(
["./program"], input=source, capture_output=True, text=True, encoding="utf-8"
)
assert result.returncode == 0
assert source.strip() in result.stdout
=== END AC runtime-utf8 ===
```
`Encoding:` is a declaration of deliberate intent, reviewable as such. Absent it, ASCII.
**Stated behavior only.** A criterion asserts behavior the source states, not behavior its phrasing
implies. "Takes no arguments", "has no configuration", and "has no side effects" describe the
surface a program offers; they are not requirements that it detect and reject an argument, a
configuration file, or a write. Where the source supplies a reference implementation, that
implementation bounds what the criteria may demand: a criterion the reference shape would fail is a
criterion the source did not ask for.
**Every check is standalone.** Drydock writes each fenced block to its own script and runs it in
its own process from the build directory. Checks in the same file share no imports, no variables,
and no execution order. A snippet that reads a name another snippet bound raises `NameError` on
every run — it reports UNVERIFIED rather than failing the build, which means it verifies nothing
and buys nothing. Each snippet imports what it uses and binds every name it reads.
**A check that shells out prints what it captured before it asserts.** `capture_output=True`
routes the runner's tally and its failing cases into a variable; asserting on the exit code alone
then discards them, and the failure reports the assertion with no evidence of what went wrong.
Print the captured `stdout` and `stderr` first, so the console, the evidence file, and the repair
pass all carry the runner's own account of the failure. Printing is for diagnosis; it is never the
oracle.
**A check that drives a suite prints its tally.** A criterion answers one yes-or-no question, so a
run that fixes a hundred cases and a run that fixes none report the same failure, and the build
reads that as a stalled repair and stops paying for calls that were working. The count is what
separates them. Where the runner reports a machine-readable summary, parse it and print the
counts on one line before asserting:
```
report = json.loads(result.stdout)
summary = report["summary"]
print(f"{summary['pass']} passed, {summary['fail']} failed, {summary['error']} errored")
assert summary["fail"] == 0 and summary["error"] == 0
```
Print the counts even when the criterion asserts on the parsed object rather than on the text.
Requesting `--json` and asserting straight off the parsed report leaves nothing on either stream,
and a suite of hundreds of cases then reports its progress as a single bit.
```markdown
## Programmatic Acceptance
=== AC health-check ===
Intent: The health endpoint returns an OK response.
from app import create_app
client = create_app().test_client()
response = client.get("/health")
assert response.status_code == 200
assert response.get_json()["status"] == "ok"
=== END AC health-check ===
=== AC suite-conformance ===
Intent: The implementation passes the conformance sections this story owns.
Suite: scoped
import os
import subprocess
import sys
# tests/run_suite.py documents RUNNER as required: it is the runner's only knowledge of the
# implementation. Read the asset and supply every variable it declares required.
result = subprocess.run(
[sys.executable, "tests/run_suite.py", "--sections", "headings,lists"],
capture_output=True, text=True,
env={**os.environ, "RUNNER": f"{os.getcwd()}/program"},
)
print(result.stdout)
print(result.stderr, file=sys.stderr)
assert result.returncode == 0
=== END AC suite-conformance ===
```
`User Acceptance` contains only Commander-observed checks that cannot be honestly automated,
such as look-and-feel or subjective workflow acceptance. Do not place deterministic behavior in
`User Acceptance`.
Do not tag an assertion with a project-acceptance ID. Sea Trials flow into planning as context for
authoring acceptance; nothing points back at them. Project acceptance is settled at `score release`
by observing the finished tree, never by looking up which assertion claimed which criterion.
**Programmatic acceptance is the story's definition of done, and a deterministic definition of
done is never sampled.** Drydock builds each block in a single pass with no iterate loop, so the
acceptance you author *is* the objective handed to the builder: sample the checks and the builder
builds to the sample. When an authoritative, externally-authored test suite already defines
"correct" for what a story builds — an imported conformance suite and its runner (for example a
specification's example suite plus a `*_tests.py` runner) — the acceptance runs that suite and
requires a full pass over the story's scope, never a hand-picked subset. A feature story binds to
the sections it owns and declares `Suite: scoped`; a terminal verification story gates on the whole
suite and declares `Suite: full`. The marker is one of the block's declaration lines and tells the
runner the check gates on the whole test suite rather than a story-scoped sample.
**A scoped selector must select something.** A check that runs a suite with a section filter
matching no cases exits zero and reports a pass while proving nothing. Select on a heading that
actually owns cases, never on a chapter title that merely contains such headings. Drydock fails a
criterion that is already green before the story's code exists.
**The runner's exit status is the verdict, and it is the whole verdict.** A conformance runner
already decides pass or fail and reports it the one way a caller can rely on. Asserting on its
printed summary as well adds no information and adds a failure mode: the case count belongs to the
installed suite rather than to the specification, and runners column-align their summaries
(`valid tests: 205 passed, 0 failed` carries two spaces), so a literal such as
`assert "valid tests: 210 passed, 0 failed" in result.stdout` is false on correct code and no
implementation can move it. The same holds for tallies of errors, skips, and warnings: a runner
with none of them commonly prints no such line at all, so requiring one is false on a clean run.
Print the captured output for diagnosis, assert `result.returncode == 0`, and stop there. This
holds for both `Suite: scoped` and `Suite: full`.
Place a whole-project deterministic suite on the story that **completes the runnable capability**
— never on a foundation step that cannot yet run it, where it would fail vacuously. Naming the suite file or asserting it is staged (`Path(...).is_file()`)
is staging, not testing: a stubbed or absent definition of done for an available suite is a defect,
not an acceptable check.
An assertion that invokes a staged asset obeys that asset's own documented interface. Read the
asset before writing the call. Every environment variable it declares required is supplied, and it
is supplied by extending the inherited environment — `env={**os.environ, "NAME": value}`. Never
write `env={"NAME": value}`: that replaces the environment, leaving the child with no `PATH`, so
nothing it invokes resolves and the assertion fails at every level of implementation quality. Never
repair a staged asset's interface by editing the asset; it is restored before grading, so the edit
is reported as tampering rather than honored.
An assertion that feeds input to a program passes it through `subprocess` `input=` rather than a
shell. When a shell is unavoidable, `printf '%s'` copies its argument verbatim: `\n` reaches the
program as a backslash and a letter, not a newline, so the program is graded on input the author
never wrote. Use `printf '%b'` or a real line break.
`COMPASS.md` uses `## Compass`, `## Constraints`, and `## Guardrails` as its body sections.
Success criteria belong in `SEA_TRIALS.md`; open questions in spike questionnaires. Do not add
those sections to `COMPASS.md`.
---
---
## Acceptance Criteria Files
**Naming rule:** any file where `AC` is a whole word in the filename is an acceptance criteria
file. `AC` must be delimited by `-`, `_`, or file boundaries — not embedded in another word.
Examples: `AC-001-login.md`, `FEATURE-LOGIN-AC.md`, `AC-NAVIGATION.md`.
`ACCEPTANCE_CRITERIA.md` does NOT follow this standard (AC is not a standalone word).
AC files enable test-driven design and a way to enforce specific behaviors without polluting the
parent specification.
**Two types of AC statements:**
| Type | Example | Rule |
|------|---------|------|
| Positive assertion | "The status badge color is red" | Reconcile into parent spec, then archive this entry |
| Negative/guardrail | "Field X must not appear on this screen" | Keep permanently in AC — these guard against model hallucination, not spec omission |
**Reconciliation:** When a positive AC fact has been implemented and verified, move it to the
parent spec body and delete the AC entry. Negative guardrails are permanent — never move them to
the spec.
**AC file format:**
```markdown
# AC: {ObjectName}
| Field | Value |
|-------------|-------|
| Version | YYYYMMDD V1 |
| Description | Acceptance criteria for {ObjectName}. |
| Parent | FEATURE-{Name}.md |
## Guardrails
- Field X must not appear on this screen.
- The delete button must not be shown to read-only users.
## Assertions
- The status badge is rendered in red when severity is HIGH.
```
**Standard AC filename forms:**
- `AC-NNN-{Name}.md` — numbered sequential acceptance-criteria ticket (authored)
- `{Parent}-AC.md` — paired directly with a spec file (e.g. `FEATURE-LOGIN-AC.md`)
- `AC-{Topic}.md` — topic-scoped AC file (e.g. `AC-NAVIGATION.md`)
**All fix and change tickets use AC naming** — `AC` as a whole word in the filename. A targeted
bug fix is expressed as a testable acceptance criterion.
---
## Dependency Declarations
`drydock plan create` scans spec file headers to populate `Depends On` and `Provides`. The
following conventions apply automatically without explicit header declaration:
| Convention | Rule |
|------------|------|
| `SCREEN-*.md` → `UI-GENERAL.md` | All screens depend on shared UI patterns |
| `DATABASE.md` → Phase 1 | Always first phase; always base context |
| `ARCHITECTURE.md` → base context | Included in every phase prompt |
| `FEATURE-*.md` providing routes → listed in `Provides` | Extracted from route tables in file |
| `SCREEN-*.md` using a route → depends on providing `FEATURE` | Matched from route references in body |
The `Depends On` and `Provides` fields form a simple directed dependency graph. `drydock plan
create` traverses this graph to assign phases, assign build order, and compute context sizes.
A file can only be built in a phase after all its `Depends On` files are built.
---
## Persistence Encapsulation (DATABASE.md scope)
`DATABASE.md` is the project's persistence contract — not SQL schema alone. It documents every
persistent store and the typed class that encapsulates it:
- **Relational tables** — schema plus the row dataclass / CRUD class / composing `Database` class.
- **Config / `.env`** — required keys and the typed `Config` class.
- **File stores** — directories and the `FileStore` class.
- **External services** — the service contract and its wrapper.
Application code reaches each store only through its class. A storage change that leaves the
interface unchanged does not invalidate downstream features.
Every `DATABASE.md` includes `## Access Patterns` and `## Persistence Interfaces` before schema
details. Access patterns name the caller, operation, store, and interface method. Persistence
interfaces name the store, public interface, module location, allowed callers, and notes.
`ARCHITECTURE.md` includes a module ownership table for persistence, configuration, file-store, and
external-service boundaries. It states which module owns each boundary and which low-level APIs that
module may access.
Any Manifest story that implements `DATABASE.md` includes `persistence.md` in `stack:` plus the
selected backend stack file such as `sqlite.md`, `postgres.md`, or `aws-dynamodb.md`.
---
## METADATA.md — Service Identity Fields
In addition to standard project fields, service repositories should declare:
```
service_name: Platform # top-level service grouping (e.g. Platform, Analytics, Tools)
service_component: GAME # component name within the service (matches directory name)
```
These fields are used by build-time service registration artifacts and by GAME's service registry
scanner to group related repositories under a named service.
---
## Authoring Conventions
**Authoring phase:** all unresolved product decisions go in `DECISIONS.json`. Do not create
`MANIFEST.md` or numbered ticket files while authoring.
**Build phase:** run `drydock plan create` once the specification is ready. Use `drydock status`
to check for spec errors and staleness before building. After a build, fold changes back by editing
the specification and re-applying with `drydock refit`.
**Spikes:** a spike is a runnable investigation. Results feed future iterations. When run, the
finding is written into the named file, resolving the matching `## Open Question` in place.
**Feature specifications:** all feature purpose, status, triggers, sequences, routes, reads,
writes, acceptance criteria, and guardrails belong in individual `FEATURE-*.md` files. README,
METADATA, and generated files do not contain feature specifications.</pblock>
<pblock label="Imported source file header" kind="section">
Imported source files
</pblock>
<pblock filename="sources/INSTRUCTIONS.md" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/INSTRUCTIONS.md" guidance="Raw User Source">
# Build Instructions: A jq Interpreter
## Objective
Build an interpreter for the jq language as described in `sources/jq-manual.txt`.
Correctness is measured by the upstream jq conformance corpus, `sources/jq.test`, taken
verbatim from jq 1.8.2. The goal is to pass every case the corpus supplies, with none
failed and none errored. The suite's size is a property of the pinned corpus; never
assert a case count.
The implementation language is Python, fixed by this Target's `TECHNOLOGY_STACK.md` and
governed by `stack/python.md`.
jq is a small language with a large semantic core. Almost every filter is a **generator**:
it takes one input and produces a stream of zero, one, or many outputs, and downstream
filters run once per upstream output. Backtracking through that stream is not an
optimisation, it is the evaluation model, and `reduce`, `foreach`, `limit`, `first`,
`label`/`break`, and the `?//` destructuring alternative are all defined in terms of it. An
implementation that treats a filter as a function returning one value will pass the early
cases and then stall permanently. Decide the evaluation model before writing builtins.
## Run Harness
`sources/full_test.sh` is the single scoring entry point. It is supplied, not authored: it
is staged verbatim into the build directory alongside the other imported assets, and
`drydock uat` runs `sh sources/full_test.sh` from the completed application root and takes
its exit code and output as the score. It reads:
```sh
#!/bin/sh
# full_test.sh — scoring entry point. Do not filter, skip, or reinterpret.
set -eu
if [ ! -x ./jq ]; then
echo "error: no executable ./jq at the application root." >&2
echo "The deliverable is an executable named jq that reads JSON on stdin." >&2
exit 1
fi
JQ="$PWD/jq" exec python3 sources/run_conformance.py
```
Before relying on any path above, run `ls sources/` in the application directory and
correct the paths in the harness against what is actually on disk. Correcting a path is
the only edit permitted to this script. Do not add flags, filters, skips, or a redirection
of the exit code.
The interface check is deliberately separate from the conformance run so that a missing
program and a genuine conformance failure are distinguishable in the evidence. `JQ` is the
harness's only knowledge of the implementation language; the harness itself is
language-neutral.
## Read-only scoring assets
These four files are the exam. They are hash-verified against the import and restored
before grading, so a modification is reported as tampering rather than honoured:
- `sources/full_test.sh` — the scoring entry point
- `sources/run_conformance.py` — the scoring instrument
- `sources/exclusions.txt` — the declared skips
- `sources/jq.test` — the conformance corpus
Do not write to them. Build `./jq` so that the supplied entry point succeeds; changing the
entry point is not a repair, and a repair pass spent editing one of these files is wasted.
## Interface contract
The program is a filter: an executable file named `jq` at the application root, invoked as
```
./jq -c '<program>'
```
with JSON on **stdin**. It writes each value the program produces to **stdout** as one
compact JSON value per line, and exits `0`.
`-c` is the only option exercised. The program need not implement any other jq
command-line option, and the manual's "Invoking jq" section is omitted from
`sources/jq-manual.txt` for that reason.
Exit codes follow jq's own, and the distinction is load-bearing because the harness grades
on it:
| Exit | Meaning |
|---|---|
| `0` | the program compiled and ran to completion |
| `3` | the program did not compile — a syntax or static error |
| `5` | the program compiled but raised at run time |
A case may legitimately emit several values and then raise; the harness compares the values
produced before the raise, so exit `5` is not by itself a failure. Exit `3` on a valid
program is always a failure. Diagnostics go to **stderr** and are never compared.
Any implementation shape that satisfies this contract is acceptable. A
`#!/usr/bin/env python3` script named `jq` that imports the real work from a package
alongside it is the obvious one; `main` should parse arguments and delegate.
## Test / verification process
The imported source files are placed in a `sources/` subdirectory of the application
directory. The only tools required are `python3` and a POSIX `sh`, both already present.
No installation step, no package download, and no network access are required at any
point.
```bash
JQ="$PWD/jq" python3 sources/run_conformance.py # the scored run
JQ="$PWD/jq" python3 sources/run_conformance.py -v # list passing cases too
JQ="$PWD/jq" python3 sources/run_conformance.py --json # machine-readable
JQ="$PWD/jq" python3 sources/run_conformance.py --list # print cases, run nothing
JQ="$PWD/jq" python3 sources/run_conformance.py --select 'reduce' # one construct at a time
JQ="$PWD/jq" python3 sources/run_conformance.py --select 'reduce' --list # size that slice
```
During development, `sh sources/full_test.sh` does the interface check and the conformance
run together, and is the same command the score is taken from.
`--select` takes a regular expression matched against the case's program text. It is how
an intermediate story runs its own slice of the corpus, and it is required, not optional.
The harness's own `--help` text for `--select` calls it a development aid and states that
the acceptance gate always runs the whole corpus. That text predates this rule and does not
govern. It is part of a read-only scoring asset and cannot be corrected in place, so it is
corrected here: where the harness's help text and this document disagree, this document is
authoritative.
**Exactly one acceptance check runs the whole corpus.** One terminal story — the last one —
runs `sh sources/full_test.sh`, asserts only `result.returncode == 0`, prints the captured
stdout and stderr so a failure can be diagnosed from the evidence, and carries the Sea
Trial. No other acceptance check may run the corpus unscoped, and none may invoke
`full_test.sh` at all. A partial implementation fails most of the corpus by construction,
so an unscoped mid-build run reports the schedule rather than a defect, and it is slow in
exact proportion to how incomplete the code is.
**Every other story runs its own slice, and the slice executes cases.** Each story's
acceptance invokes `sources/run_conformance.py` with a `--select` expression scoped to the
construct that story implements, supplies `JQ`, and asserts `result.returncode == 0`. Those
are exactly the cases the story's code is supposed to pass, so the run is neither slow nor
red by construction, and the corpus goes green in the order the plan builds it.
`--list` prints the matching cases and runs nothing. Use it while planning, to size and
inspect a selector before committing to it. An acceptance check that invokes it executes
nothing, passes before the story's code exists, and steers no repair; such a check is a
defect. The one exception is the story whose only obligation is that the corpus parses, the
exclusion list applies, and the harness starts — it implements none of the behaviour under
test, so listing is the correct thing for it to assert.
A selector matching no case is a defect too: it buys the story no coverage and reports
success. Check the count with `--list` while planning and widen the expression until it
covers the story's construct. Together the slices cover the corpus; a case no slice reaches
is first executed by the terminal gate, where a failure arrives with the whole build
already spent and no story to attribute it to.
No acceptance check may assert that an imported or staged file merely exists — a
file-presence check is not acceptance.
The summary line is:
```
jq conformance: NNN passed, N failed, N errored, N skipped (corpus jq.test @ jq-1.8.2)
```
The harness reserves exit `2` for its own faults — a missing corpus, an unset `JQ`, a
stale exclusion. Exit `2` never means the interpreter is wrong.
## The corpus format
`sources/jq.test` documents its own format in its header. Cases are separated by blank
lines; blank lines and `#` lines are ignored. A case is a program line, an input line, and
then the expected output values, one per line. A case preceded by `%%FAIL` is a program
that must be **rejected at compile time**: the following lines are upstream jq's
diagnostic, which this harness records but never compares. Reproducing jq's exact error
text is reverse-engineering a C implementation, not conforming to a specification, so a
`%%FAIL` case passes on exit `3` alone.
Values are compared structurally, not textually. `1` and `1.0` are the same jq value; so
are two objects whose keys are printed in a different order. Formatting of output is
therefore not under test, but the **number and order** of values is.
## Declared exclusions
`sources/exclusions.txt` names the corpus cases this kit cannot run, with the reason. They
are the module-loader cases: `import` and `include` resolved against a search path of
fixture files that this kit's flat source import cannot carry. They are reported as
`skipped` and are not part of the score.
The module *grammar* cases are **not** excluded and must pass. `module (.+1); 0`,
`module []; 0`, `include "a" (.+1); 0`, `include "a" []; 0`, `include "\ "; 0`,
`include "\(a)"; 0`, and `%::wat` are all `%%FAIL` cases: the front end must parse the
module syntax far enough to reject them, without ever touching the filesystem.
## Source Roles
Record this table in the Analysis so every asset is staged onto disk in the build
directory. `sources/jq-manual.txt`, `sources/jq.test`, `sources/parser.y`, and
`sources/lexer.l` are large and must be readable from disk during implementation rather
than carried in prompt text.
| Source | Role | Plan disposition | Build disposition |
|---|---|---|---|
| `jq-manual.txt` | normative specification | context | stage |
| `jq.test` | conformance test suite | context | stage |
| `parser.y` | normative specification | context | stage |
| `lexer.l` | normative specification | context | stage |
| `builtin.jq` | reference implementation | context | stage |
| `run_conformance.py` | conformance harness | context | stage |
| `full_test.sh` | conformance harness | context | stage |
| `exclusions.txt` | conformance harness | context | stage |
| `INSTRUCTIONS.md` | author intent | context | prompt-only |
What each staged file is for:
- `sources/jq-manual.txt` — the jq language manual at 1.8.2, rendered to plain text. The
primary specification, and the normative description of every builtin.
- `sources/jq.test` — the conformance corpus. Also the most precise available statement of
the semantics, especially for generators and backtracking.
- `sources/parser.y` — upstream's yacc grammar. The authority on operator precedence,
associativity, and the shape of every syntactic form.
- `sources/lexer.l` — upstream's lexer. The authority on tokens, string interpolation, and
escape handling.
- `sources/builtin.jq` — the subset of jq's builtins that upstream defines in jq itself.
Read it as a specification of those builtins' semantics.
- `sources/run_conformance.py`, `sources/full_test.sh`, `sources/exclusions.txt` — the
scoring instruments, read-only as stated above.
## Suggested implementation order
The difficulty is concentrated in one place — the evaluation model — and not spread evenly
across the corpus. Build the core correctly before reaching for coverage.
1. **Lexer and parser.** Follow `sources/lexer.l` and `sources/parser.y` directly. Produce
an AST. Precedence, `?` suffixes, string interpolation, and the `def` forms are all
settled there. Reject invalid programs with exit `3`.
2. **The generator core.** Evaluate a filter as something that yields a stream of values:
`.`, literals, `|`, `,`, field access, iteration, arithmetic, comparison, and
`empty`. Every later feature is expressed in terms of this. Get `[.[] | f]`,
cartesian products over multi-output arguments, and short-circuiting right.
3. **Paths and assignment.** `path(f)`, `getpath`, `setpath`, `delpaths`, `del`, and then
`=`, `|=`, `+=`, and friends. Assignment is defined over path expressions, so this
cannot precede step 2.
4. **Control flow.** `if`/`then`/`elif`/`else`/`end`, `try`/`catch` and `?`, `//`,
`reduce`, `foreach`, `label`/`break`, `limit`, `first`, `last`, `until`, `while`,
`recurse`. This is where backtracking is tested hardest.
5. **Functions, variables, and destructuring.** `def` with arity and closures, `as`
bindings, object and array patterns, and the `?//` alternative operator.
6. **Builtins.** Work outward from `sources/builtin.jq` and the manual: strings, arrays,
objects, `sort_by`/`group_by`/`unique_by`, `@base64`/`@uri`/`@csv`/`@tsv`/`@sh`
formats, the date functions, `tostream`, `input`/`inputs`, `$__loc__`, `debug`.
7. **Numbers and edge cases.** `nan`, `infinite`, integer/float equality, large literals,
and the `have_decnum` builtin — return `false` from it and the corpus takes its
non-decNumber branch, which native floats satisfy.
The manual is normative and the corpus is precise. Follow both directly rather than
inferring behaviour from jq's printed output.
## Definition of Done
- `sh sources/full_test.sh` runs cleanly with zero errors and exits zero.
- The program satisfies the `./jq -c` → stdin → one-JSON-value-per-line → exit-code
contract.
- Every corpus case that runs passes: the failed and errored counts are both zero, and the
skipped count matches the declared exclusions. The harness exit status is the verdict and
the whole verdict — assert `returncode == 0` and stop there. Do not assert on the text of
the summary line at all: the case totals belong to the pinned corpus, and a check that
reads a runner's printed output is measuring the runner rather than the interpreter.
- Do not create acceptance checks asserting that imported or staged files merely exist.
- The interpreter is written from the specification. **Every third-party jq
implementation or binding is forbidden** — `jq.py`, `pyjq`, `jqlang`, `gojq`, `jaq`, and
any other — as is shelling out to a system `jq` binary. A wrapper around real jq scores
perfectly and makes the exercise meaningless.
- The project declares no third-party runtime dependency. The standard library is
sufficient: `json`, `decimal`, `math`, `re`, `datetime`, `time`, `base64`, `unicodedata`,
`itertools`, `functools`, `dataclasses`, `argparse`, `sys`.
- No network access at any point, including at test time. No package is installed, and no
tool beyond `python3` and POSIX `sh` is invoked.
- Deliver a concise project `README.md` documenting the stdin/stdout interface, the exit
codes, and the `sh sources/full_test.sh` command.</pblock>
<pblock filename="sources/builtin.jq" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/builtin.jq">
def halt_error: halt_error(5);
def error(msg): msg|error;
def map(f): [.[] | f];
def select(f): if f then . else empty end;
def sort_by(f): _sort_by_impl(map([f]));
def group_by(f): _group_by_impl(map([f]));
def unique_by(f): _unique_by_impl(map([f]));
def max_by(f): _max_by_impl(map([f]));
def min_by(f): _min_by_impl(map([f]));
def add(f): reduce f as $x (null; . + $x);
def add: add(.[]);
def del(f): delpaths([path(f)]);
def abs: if . < 0 then - . else . end;
def _assign(paths; $value): reduce path(paths) as $p (.; setpath($p; $value));
def _modify(paths; update):
reduce path(paths) as $p ([., []];
. as $dot
| null
| label $out
| ($dot[0] | getpath($p)) as $v
| (
( $$$$v
| update
| (., break $out) as $v
| $$$$dot
| setpath([0] + $p; $v)
),
(
$$$$dot
| setpath([1, (.[1] | length)]; $p)
)
)
) | . as $dot | $dot[0] | delpaths($dot[1]);
def map_values(f): .[] |= f;
# recurse
def recurse(f): def r: ., (f | r); r;
def recurse(f; cond): def r: ., (f | select(cond) | r); r;
def recurse: recurse(.[]?);
def to_entries: [keys_unsorted[] as $k | {key: $k, value: .[$k]}];
def from_entries: map({ (.key // .Key // .name // .Name):
if has("value") then .value else .Value end }) | add // {};
def with_entries(f): to_entries | map(f) | from_entries;
def reverse: [.[length - 1 - range(0;length)]];
def indices($i): if type == "array" and ($i|type) == "array" then .[$i]
elif type == "array" then .[[$i]]
elif type == "string" and ($i|type) == "string" then _strindices($i)
else .[$i] end;
def index($i): indices($i) | .[0]; # TODO: optimize
def rindex($i): indices($i) | .[-1:][0]; # TODO: optimize
def paths: path(recurse)|select(length > 0);
def paths(node_filter): path(recurse|select(node_filter))|select(length > 0);
def isfinite: type == "number" and (isinfinite | not);
def arrays: select(type == "array");
def objects: select(type == "object");
def iterables: select(type|. == "array" or . == "object");
def booleans: select(type == "boolean");
def numbers: select(type == "number");
def normals: select(isnormal);
def finites: select(isfinite);
def strings: select(type == "string");
def nulls: select(. == null);
def values: select(. != null);
def scalars: select(type|. != "array" and . != "object");
def join($x): reduce .[] as $i (null;
(if .==null then "" else .+$x end) +
($i | if type=="boolean" or type=="number" then tostring else .//"" end)
) // "";
def _flatten($x): reduce .[] as $i ([]; if $i | type == "array" and $x != 0 then . + ($i | _flatten($x-1)) else . + [$i] end);
def flatten($x): if $x < 0 then error("flatten depth must not be negative") else _flatten($x) end;
def flatten: _flatten(-1);
def range($x): range(0;$x);
def fromdateiso8601: strptime("%Y-%m-%dT%H:%M:%SZ")|mktime;
def todateiso8601: strftime("%Y-%m-%dT%H:%M:%SZ");
def fromdate: fromdateiso8601;
def todate: todateiso8601;
def ltrimstr($left): if startswith($left) then .[$left | length:] end;
def rtrimstr($right): if endswith($right) then .[:length - ($right | length)] end;
def trimstr($val): ltrimstr($val) | rtrimstr($val);
def match(re; mode): _match_impl(re; mode; false)|.[];
def match($val): ($val|type) as $vt | if $vt == "string" then match($val; null)
elif $vt == "array" and ($val | length) > 1 then match($val[0]; $val[1])
elif $vt == "array" and ($val | length) > 0 then match($val[0]; null)
else error( $vt + " not a string or array") end;
def test(re; mode): _match_impl(re; mode; true);
def test($val): ($val|type) as $vt | if $vt == "string" then test($val; null)
elif $vt == "array" and ($val | length) > 1 then test($val[0]; $val[1])
elif $vt == "array" and ($val | length) > 0 then test($val[0]; null)
else error( $vt + " not a string or array") end;
def capture(re; mods): match(re; mods) | reduce ( .captures | .[] | select(.name != null) | { (.name) : .string } ) as $pair ({}; . + $pair);
def capture($val): ($val|type) as $vt | if $vt == "string" then capture($val; null)
elif $vt == "array" and ($val | length) > 1 then capture($val[0]; $val[1])
elif $vt == "array" and ($val | length) > 0 then capture($val[0]; null)
else error( $vt + " not a string or array") end;
def scan($re; $flags):
match($re; "g" + $flags)
| if (.captures|length > 0)
then [ .captures | .[] | .string ]
else .string
end;
def scan($re): scan($re; null);
# splits/1 produces a stream; split/1 is retained for backward compatibility.
def splits($re; $flags):
.[foreach (match($re; $flags+"g"), null) as {$offset, $length}
(null; {start: .next, end: $offset, next: ($offset+$length)})];
def splits($re): splits($re; null);
# split emits an array for backward compatibility
def split($re; $flags): [ splits($re; $flags) ];
# If s contains capture variables, then create a capture object and pipe it to s, bearing
# in mind that s could be a stream
def sub($re; s; $flags):
. as $in
| (reduce match($re; $flags) as $edit
({result: [], previous: 0};
$in[ .previous: ($edit | .offset) ] as $gap
# create the "capture" objects (one per item in s)
| [reduce ( $edit | .captures | .[] | select(.name != null) | { (.name) : .string } ) as $pair
({}; . + $pair) | s ] as $inserts
| reduce range(0; $inserts|length) as $ix (.; .result[$ix] += $gap + $inserts[$ix])
| .previous = ($edit | .offset + .length ) )
| .result[] + $in[.previous:] )
// $in;
def sub($re; s): sub($re; s; "");
def gsub($re; s; flags): sub($re; s; flags + "g");
def gsub($re; s): sub($re; s; "g");
########################################################################
# generic iterator/generator
def while(cond; update):
def _while:
if cond then ., (update | _while) else empty end;
_while;
def until(cond; next):
def _until:
if cond then . else (next|_until) end;
_until;
def limit($n; expr):
if $n > 0 then label $out | foreach expr as $item ($n; . - 1; $item, if . <= 0 then break $out else empty end)
elif $n == 0 then empty
else error("limit doesn't support negative count") end;
def skip($n; expr):
if $n > 0 then foreach expr as $item ($n; . - 1; if . < 0 then $item else empty end)
elif $n == 0 then expr
else error("skip doesn't support negative count") end;
# range/3, with a `by` expression argument
def range($init; $upto; $by):
if $by > 0 then $init|while(. < $upto; . + $by)
elif $by < 0 then $init|while(. > $upto; . + $by)
else empty end;
def first(g): label $out | g | ., break $out;
def isempty(g): first((g|false), true);
def all(generator; condition): isempty(generator|condition and empty);
def any(generator; condition): isempty(generator|condition or empty)|not;
def all(condition): all(.[]; condition);
def any(condition): any(.[]; condition);
def all: all(.[]; .);
def any: any(.[]; .);
def nth($n; g):
if $n < 0 then error("nth doesn't support negative indices")
else first(skip($n; g)) end;
def first: .[0];
def last: .[-1];
def nth($n): .[$n];
def combinations:
if length == 0 then [] else
.[0][] as $x
| (.[1:] | combinations) as $y
| [$x] + $y
end;
def combinations(n):
. as $dot
| [range(n) | $dot]
| combinations;
# transpose a possibly jagged matrix, quickly;
# rows are padded with nulls so the result is always rectangular.
def transpose: [range(0; map(length)|max // 0) as $i | [.[][$i]]];
def in(xs): . as $x | xs | has($x);
def inside(xs): . as $x | xs | contains($x);
def repeat(exp):
def _repeat:
exp, _repeat;
_repeat;
def inputs: try repeat(input) catch if .=="break" then empty else error end;
# like ruby's downcase - only characters A to Z are affected
def ascii_downcase:
explode | map( if 65 <= . and . <= 90 then . + 32 else . end) | implode;
# like ruby's upcase - only characters a to z are affected
def ascii_upcase:
explode | map( if 97 <= . and . <= 122 then . - 32 else . end) | implode;
# Streaming utilities
def truncate_stream(stream):
. as $n | null | stream | . as $input | if (.[0]|length) > $n then setpath([0];$input[0][$n:]) else empty end;
def fromstream(i): {x: null, e: false} as $init |
# .x = object being built; .e = emit and reset state
foreach i as $i ($init
; if .e then $init else . end
| if $i|length == 2
then setpath(["e"]; $i[0]|length==0) | setpath(["x"]+$i[0]; $i[1])
else setpath(["e"]; $i[0]|length==1) end
; if .e then .x else empty end);
def tostream:
path(def r: (.[]?|r), .; r) as $p |
getpath($p) |
reduce path(.[]?) as $q ([$p, .]; [$p+$q]);
# Apply f to composite entities recursively, and to atoms
def walk(f):
def w:
if type == "object"
then map_values(w)
elif type == "array" then map(w)
else .
end
| f;
w;
# pathexps could be a stream of dot-paths
def pick(pathexps):
. as $in
| reduce path(pathexps) as $a (null;
setpath($a; $in|getpath($a)) );
# ensure the output of debug(m1,m2) is kept together:
def debug(msgs): (msgs | debug | empty), .;
# SQL-ish operators here:
def INDEX(stream; idx_expr):
reduce stream as $row ({}; .[$row|idx_expr|tostring] = $row);
def INDEX(idx_expr): INDEX(.[]; idx_expr);
def JOIN($idx; idx_expr):
[.[] | [., $idx[idx_expr]]];
def JOIN($idx; stream; idx_expr):
stream | [., $idx[idx_expr]];
def JOIN($idx; stream; idx_expr; join_expr):
stream | [., $idx[idx_expr]] | join_expr;
def IN(s): any(s == .; .);
def IN(src; s): any(src == s; .);</pblock>
<pblock filename="sources/exclusions.txt" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/exclusions.txt">
# exclusions.txt — corpus cases this kit cannot run, and why.
#
# The corpus in sources/jq.test is byte-for-byte upstream and is never edited. Where a case
# cannot run under this kit's harness, it is named here instead, so every skip is visible,
# reasoned, and auditable against the upstream file. This file is a scoring asset: it is
# hash-verified against the import and restored before grading.
#
# One verbatim program line per entry. An entry that matches no case in the corpus is a hard
# error (exit 2), not a shrug — a silent no-op would quietly re-admit a case the kit cannot run
# if the corpus pin ever moved.
#
# Nothing is excluded for being hard. The module-loader cases below are excluded because the
# kit physically cannot deliver their inputs, not because the semantics are difficult.
# --------------------------------------------------------------------------------------------
# Module loading from disk.
#
# These cases resolve `import` and `include` against a module search path supplied by jq's -L
# flag, reading roughly twenty fixture files spread across nested directories upstream
# (tests/modules/{b,c,lib/jq/e,home2/.jq,...}). Drydock copies a kit's declared sources into the
# application flattened by basename, so that directory tree cannot be carried, and the interface
# this kit fixes exercises no flag but -c.
#
# Only the loader cases are excluded. The module *grammar* cases — `module (.+1); 0`,
# `module []; 0`, `include "a" (.+1); 0`, `include "a" []; 0`, `include "\ "; 0`,
# `include "\(a)"; 0`, and `%::wat` — remain in the scored set: they are parse errors that a
# correct front end rejects without ever touching the filesystem.
# --------------------------------------------------------------------------------------------
import "a" as foo; import "b" as bar; def fooa: foo::a; [fooa, bar::a, bar::b, foo::a]
import "c" as foo; [foo::a, foo::c]
include "c"; [a, c]
import "data" as $e; import "data" as $d; [$d[].this,$e[].that,$d::d[].this,$e::e[].that]|join(";")
import "data" as $a; import "data" as $b; def f: {$a, $b}; f
include "shadow1"; e
include "shadow1"; include "shadow2"; e
import "shadow1" as f; import "shadow2" as f; import "shadow1" as e; [e::e, f::e]
import "syntaxerror" as e; .
import "test_bind_order" as check; check::check
# `modulemeta` reports a module's declared dependencies and definitions. Its three cases take
# the module name "c" as input and read tests/modules/c/c.jq from the search path, so they fail
# for the same reason as the loader cases above.
modulemeta
modulemeta | .deps | length
modulemeta | .defs | length</pblock>
<pblock filename="sources/full_test.sh" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/full_test.sh">
#!/bin/sh
# full_test.sh — scoring entry point. Do not filter, skip, or reinterpret.
#
# `drydock uat` runs `sh sources/full_test.sh` from the completed application root and takes its
# exit code and output as the score. The interface check is separate from the conformance run so
# that a missing or non-executable program and a genuine conformance failure are distinguishable
# in the evidence. JQ is the harness's only knowledge of the implementation language; the
# harness itself is language-neutral.
set -eu
if [ ! -x ./jq ]; then
echo "error: no executable ./jq at the application root." >&2
echo "The deliverable is an executable named jq that reads JSON on stdin." >&2
exit 1
fi
JQ="$PWD/jq" exec python3 sources/run_conformance.py</pblock>
<pblock filename="sources/jq-manual.txt" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/jq-manual.txt">
The jq Language Manual
======================
Rendered from the jq manual at tag jq-1.8.2 (docs/content/manual/v1.8/manual.yml).
See PROVENANCE.md for the upstream hash.
This is the normative description of the jq language and is the primary specification
for this project. Section and entry titles, prose, and worked examples are upstream's,
verbatim and in document order. The manual's "Invoking jq" and "Colors" sections are
omitted: they describe jq's command-line option surface, which this project does not
implement and the conformance corpus does not exercise.
Worked examples read:
Example: <the jq program>
Input: <the JSON input>
Output: <each JSON value the program produces, one per line>
Introduction
------------
A jq program is a "filter": it takes an input, and produces an
output. There are a lot of builtin filters for extracting a
particular field of an object, or converting a number to a string,
or various other standard tasks.
Filters can be combined in various ways - you can pipe the output of
one filter into another filter, or collect the output of a filter
into an array.
Some filters produce multiple results, for instance there's one that
produces all the elements of its input array. Piping that filter
into a second runs the second filter for each element of the
array. Generally, things that would be done with loops and iteration
in other languages are just done by gluing filters together in jq.
It's important to remember that every filter has an input and an
output. Even literals like "hello" or 42 are filters - they take an
input but always produce the same literal as output. Operations that
combine two filters, like addition, generally feed the same input to
both and combine the results. So, you can implement an averaging
filter as `add / length` - feeding the input array both to the `add`
filter and the `length` filter and then performing the division.
But that's getting ahead of ourselves. :) Let's start with something
simpler:
============================================================================
SECTION: Basic filters
============================================================================
----------------------------------------------------------------------------
Identity: `.`
----------------------------------------------------------------------------
The absolute simplest filter is `.` . This filter takes its
input and produces the same value as output. That is, this
is the identity operator.
Since jq by default pretty-prints all output, a trivial
program consisting of nothing but `.` can be used to format
JSON output from, say, `curl`.
Although the identity filter never modifies the value of its
input, jq processing can sometimes make it appear as though
it does. For example, using the current implementation of
jq, we would see that the expression:
1E1234567890 | .
produces `1.7976931348623157e+308` on at least one platform.
This is because, in the process of parsing the number, this
particular version of jq has converted it to an IEEE754
double-precision representation, losing precision.
The way in which jq handles numbers has changed over time
and further changes are likely within the parameters set by
the relevant JSON standards. Moreover, build configuration
options can alter how jq processes numbers.
The following remarks are therefore offered with the
understanding that they are intended to be descriptive of the
current version of jq and should not be interpreted as being
prescriptive:
(1) Any arithmetic operation on a number that has not
already been converted to an IEEE754 double precision
representation will trigger a conversion to the IEEE754
representation.
(2) jq will attempt to maintain the original decimal
precision of number literals (if the `--disable-decnum`
build configuration option was not used), but in expressions
such `1E1234567890`, precision will be lost if the exponent
is too large.
(3) Comparisons are carried out using the untruncated
big decimal representation of numbers if available, as
illustrated in one of the following examples.
The examples below use the builtin function `have_decnum` in
order to demonstrate the expected effects of using / not
using the `--disable-decnum` build configuration option, and
also to allow automated tests derived from these examples to
pass regardless of whether that option is used.
Example: .
Input: "Hello, world!"
Output: "Hello, world!"
Example: .
Input: 0.12345678901234567890123456789
Output: 0.12345678901234567890123456789
Example: [., tojson] == if have_decnum then [12345678909876543212345,"12345678909876543212345"] else [12345678909876543000000,"12345678909876543000000"] end
Input: 12345678909876543212345
Output: true
Example: [1234567890987654321,-1234567890987654321 | tojson] == if have_decnum then ["1234567890987654321","-1234567890987654321"] else ["1234567890987654400","-1234567890987654400"] end
Input: null
Output: true
Example: . < 0.12345678901234567890123456788
Input: 0.12345678901234567890123456789
Output: false
Example: map([., . == 1]) | tojson == if have_decnum then "[[1,true],[1.000,true],[1.0,true],[1.00,true]]" else "[[1,true],[1,true],[1,true],[1,true]]" end
Input: [1, 1.000, 1.0, 100e-2]
Output: true
Example: . as $big | [$big, $big + 1] | map(. > 10000000000000000000000000000000) | . == if have_decnum then [true, false] else [false, false] end
Input: 10000000000000000000000000000001
Output: true
----------------------------------------------------------------------------
Object Identifier-Index: `.foo`, `.foo.bar`
----------------------------------------------------------------------------
The simplest *useful* filter has the form `.foo`. When given a
JSON object (aka dictionary or hash) as input, `.foo` produces
the value at the key "foo" if the key is present, or null otherwise.
A filter of the form `.foo.bar` is equivalent to `.foo | .bar`.
The `.foo` syntax only works for simple, identifier-like keys, that
is, keys that are all made of alphanumeric characters and
underscore, and which do not start with a digit.
If the key contains special characters or starts with a digit,
you need to surround it with double quotes like this:
`."foo$"`, or else `.["foo$"]`.
For example `.["foo::bar"]` and `.["foo.bar"]` work while
`.foo::bar` does not.
Example: .foo
Input: {"foo": 42, "bar": "less interesting data"}
Output: 42
Example: .foo
Input: {"notfoo": true, "alsonotfoo": false}
Output: null
Example: .["foo"]
Input: {"foo": 42}
Output: 42
----------------------------------------------------------------------------
Optional Object Identifier-Index: `.foo?`
----------------------------------------------------------------------------
Just like `.foo`, but does not output an error when `.` is not an
object.
Example: .foo?
Input: {"foo": 42, "bar": "less interesting data"}
Output: 42
Example: .foo?
Input: {"notfoo": true, "alsonotfoo": false}
Output: null
Example: .["foo"]?
Input: {"foo": 42}
Output: 42
Example: [.foo?]
Input: [1,2]
Output: []
----------------------------------------------------------------------------
Object Index: `.[<string>]`
----------------------------------------------------------------------------
You can also look up fields of an object using syntax like
`.["foo"]` (`.foo` above is a shorthand version of this, but
only for identifier-like strings).
----------------------------------------------------------------------------
Array Index: `.[<number>]`
----------------------------------------------------------------------------
When the index value is an integer, `.[<number>]` can index
arrays. Arrays are zero-based, so `.[2]` returns the third
element.
Negative indices are allowed, with -1 referring to the last
element, -2 referring to the next to last element, and so on.
Example: .[0]
Input: [{"name":"JSON", "good":true}, {"name":"XML", "good":false}]
Output: {"name":"JSON", "good":true}
Example: .[2]
Input: [{"name":"JSON", "good":true}, {"name":"XML", "good":false}]
Output: null
Example: .[-2]
Input: [1,2,3]
Output: 2
----------------------------------------------------------------------------
Array/String Slice: `.[<number>:<number>]`
----------------------------------------------------------------------------
The `.[<number>:<number>]` syntax can be used to return a
subarray of an array or substring of a string. The array
returned by `.[10:15]` will be of length 5, containing the
elements from index 10 (inclusive) to index 15 (exclusive).
Either index may be negative (in which case it counts
backwards from the end of the array), or omitted (in which
case it refers to the start or end of the array).
Indices are zero-based.
Example: .[2:4]
Input: ["a","b","c","d","e"]
Output: ["c", "d"]
Example: .[2:4]
Input: "abcdefghi"
Output: "cd"
Example: .[:3]
Input: ["a","b","c","d","e"]
Output: ["a", "b", "c"]
Example: .[-2:]
Input: ["a","b","c","d","e"]
Output: ["d", "e"]
----------------------------------------------------------------------------
Array/Object Value Iterator: `.[]`
----------------------------------------------------------------------------
If you use the `.[index]` syntax, but omit the index
entirely, it will return *all* of the elements of an
array. Running `.[]` with the input `[1,2,3]` will produce the
numbers as three separate results, rather than as a single
array. A filter of the form `.foo[]` is equivalent to
`.foo | .[]`.
You can also use this on an object, and it will return all
the values of the object.
Note that the iterator operator is a generator of values.
Example: .[]
Input: [{"name":"JSON", "good":true}, {"name":"XML", "good":false}]
Output: {"name":"JSON", "good":true}
{"name":"XML", "good":false}
Example: .[]
Input: []
Output: (no output)
Example: .foo[]
Input: {"foo":[1,2,3]}
Output: 1
2
3
Example: .[]
Input: {"a": 1, "b": 1}
Output: 1
1
----------------------------------------------------------------------------
`.[]?`
----------------------------------------------------------------------------
Like `.[]`, but no errors will be output if . is not an array
or object. A filter of the form `.foo[]?` is equivalent to
`.foo | .[]?`.
----------------------------------------------------------------------------
Comma: `,`
----------------------------------------------------------------------------
If two filters are separated by a comma, then the
same input will be fed into both and the two filters' output
value streams will be concatenated in order: first, all of the
outputs produced by the left expression, and then all of the
outputs produced by the right. For instance, filter `.foo,
.bar`, produces both the "foo" fields and "bar" fields as
separate outputs.
The `,` operator is one way to construct generators.
Example: .foo, .bar
Input: {"foo": 42, "bar": "something else", "baz": true}
Output: 42
"something else"
Example: .user, .projects[]
Input: {"user":"stedolan", "projects": ["jq", "wikiflow"]}
Output: "stedolan"
"jq"
"wikiflow"
Example: .[4,2]
Input: ["a","b","c","d","e"]
Output: "e"
"c"
----------------------------------------------------------------------------
Pipe: `|`
----------------------------------------------------------------------------
The | operator combines two filters by feeding the output(s) of
the one on the left into the input of the one on the right. It's
similar to the Unix shell's pipe, if you're used to that.
If the one on the left produces multiple results, the one on
the right will be run for each of those results. So, the
expression `.[] | .foo` retrieves the "foo" field of each
element of the input array. This is a cartesian product,
which can be surprising.
Note that `.a.b.c` is the same as `.a | .b | .c`.
Note too that `.` is the input value at the particular stage
in a "pipeline", specifically: where the `.` expression appears.
Thus `.a | . | .b` is the same as `.a.b`, as the `.` in the
middle refers to whatever value `.a` produced.
Example: .[] | .name
Input: [{"name":"JSON", "good":true}, {"name":"XML", "good":false}]
Output: "JSON"
"XML"
----------------------------------------------------------------------------
Parenthesis
----------------------------------------------------------------------------
Parenthesis work as a grouping operator just as in any typical
programming language.
Example: (. + 2) * 5
Input: 1
Output: 15
============================================================================
SECTION: Types and Values
============================================================================
jq supports the same set of datatypes as JSON - numbers,
strings, booleans, arrays, objects (which in JSON-speak are
hashes with only string keys), and "null".
Booleans, null, strings and numbers are written the same way as
in JSON. Just like everything else in jq, these simple
values take an input and produce an output - `42` is a valid jq
expression that takes an input, ignores it, and returns 42
instead.
Numbers in jq are internally represented by their IEEE754 double
precision approximation. Any arithmetic operation with numbers,
whether they are literals or results of previous filters, will
produce a double precision floating point result.
However, when parsing a literal jq will store the original literal
string. If no mutation is applied to this value then it will make
to the output in its original form, even if conversion to double
would result in a loss.
----------------------------------------------------------------------------
Array construction: `[]`
----------------------------------------------------------------------------
As in JSON, `[]` is used to construct arrays, as in
`[1,2,3]`. The elements of the arrays can be any jq
expression, including a pipeline. All of the results produced
by all of the expressions are collected into one big array.
You can use it to construct an array out of a known quantity
of values (as in `[.foo, .bar, .baz]`) or to "collect" all the
results of a filter into an array (as in `[.items[].name]`)
Once you understand the "," operator, you can look at jq's array
syntax in a different light: the expression `[1,2,3]` is not using a
built-in syntax for comma-separated arrays, but is instead applying
the `[]` operator (collect results) to the expression 1,2,3 (which
produces three different results).
If you have a filter `X` that produces four results,
then the expression `[X]` will produce a single result, an
array of four elements.
Example: [.user, .projects[]]
Input: {"user":"stedolan", "projects": ["jq", "wikiflow"]}
Output: ["stedolan", "jq", "wikiflow"]
Example: [ .[] | . * 2]
Input: [1, 2, 3]
Output: [2, 4, 6]
----------------------------------------------------------------------------
Object Construction: `{}`
----------------------------------------------------------------------------
Like JSON, `{}` is for constructing objects (aka
dictionaries or hashes), as in: `{"a": 42, "b": 17}`.
If the keys are "identifier-like", then the quotes can be left
off, as in `{a:42, b:17}`. Variable references as key
expressions use the value of the variable as the key. Key
expressions other than constant literals, identifiers, or
variable references, need to be parenthesized, e.g.,
`{("a"+"b"):59}`.
The value can be any expression (although you may need to wrap
it in parentheses if, for example, it contains colons), which
gets applied to the {} expression's input (remember, all
filters have an input and an output).
{foo: .bar}
will produce the JSON object `{"foo": 42}` if given the JSON
object `{"bar":42, "baz":43}` as its input. You can use this
to select particular fields of an object: if the input is an
object with "user", "title", "id", and "content" fields and
you just want "user" and "title", you can write
{user: .user, title: .title}
Because that is so common, there's a shortcut syntax for it:
`{user, title}`.
If one of the expressions produces multiple results,
multiple dictionaries will be produced. If the input's
{"user":"stedolan","titles":["JQ Primer", "More JQ"]}
then the expression
{user, title: .titles[]}
will produce two outputs:
{"user":"stedolan", "title": "JQ Primer"}
{"user":"stedolan", "title": "More JQ"}
Putting parentheses around the key means it will be evaluated as an
expression. With the same input as above,
{(.user): .titles}
produces
{"stedolan": ["JQ Primer", "More JQ"]}
Variable references as keys use the value of the variable as
the key. Without a value then the variable's name becomes the
key and its value becomes the value,
"f o o" as $foo | "b a r" as $bar | {$foo, $bar:$foo}
produces
{"foo":"f o o","b a r":"f o o"}
Example: {user, title: .titles[]}
Input: {"user":"stedolan","titles":["JQ Primer", "More JQ"]}
Output: {"user":"stedolan", "title": "JQ Primer"}
{"user":"stedolan", "title": "More JQ"}
Example: {(.user): .titles}
Input: {"user":"stedolan","titles":["JQ Primer", "More JQ"]}
Output: {"stedolan": ["JQ Primer", "More JQ"]}
----------------------------------------------------------------------------
Recursive Descent: `..`
----------------------------------------------------------------------------
Recursively descends `.`, producing every value. This is the
same as the zero-argument `recurse` builtin (see below). This
is intended to resemble the XPath `//` operator. Note that
`..a` does not work; use `.. | .a` instead. In the example
below we use `.. | .a?` to find all the values of object keys
"a" in any object found "below" `.`.
This is particularly useful in conjunction with `path(EXP)`
(also see below) and the `?` operator.
Example: .. | .a?
Input: [[{"a":1}]]
Output: 1
============================================================================
SECTION: Builtin operators and functions
============================================================================
Some jq operators (for instance, `+`) do different things
depending on the type of their arguments (arrays, numbers,
etc.). However, jq never does implicit type conversions. If you
try to add a string to an object you'll get an error message and
no result.
Please note that all numbers are converted to IEEE754 double precision
floating point representation. Arithmetic and logical operators are working
with these converted doubles. Results of all such operations are also limited
to the double precision.
The only exception to this behaviour of number is a snapshot of original number
literal. When a number which originally was provided as a literal is never
mutated until the end of the program then it is printed to the output in its
original literal form. This also includes cases when the original literal
would be truncated when converted to the IEEE754 double precision floating point
number.
----------------------------------------------------------------------------
Addition: `+`
----------------------------------------------------------------------------
The operator `+` takes two filters, applies them both
to the same input, and adds the results together. What
"adding" means depends on the types involved:
- **Numbers** are added by normal arithmetic.
- **Arrays** are added by being concatenated into a larger array.
- **Strings** are added by being joined into a larger string.
- **Objects** are added by merging, that is, inserting all
the key-value pairs from both objects into a single
combined object. If both objects contain a value for the
same key, the object on the right of the `+` wins. (For
recursive merge use the `*` operator.)
`null` can be added to any value, and returns the other
value unchanged.
Example: .a + 1
Input: {"a": 7}
Output: 8
Example: .a + .b
Input: {"a": [1,2], "b": [3,4]}
Output: [1,2,3,4]
Example: .a + null
Input: {"a": 1}
Output: 1
Example: .a + 1
Input: {}
Output: 1
Example: {a: 1} + {b: 2} + {c: 3} + {a: 42}
Input: null
Output: {"a": 42, "b": 2, "c": 3}
----------------------------------------------------------------------------
Subtraction: `-`
----------------------------------------------------------------------------
As well as normal arithmetic subtraction on numbers, the `-`
operator can be used on arrays to remove all occurrences of
the second array's elements from the first array.
Example: 4 - .a
Input: {"a":3}
Output: 1
Example: . - ["xml", "yaml"]
Input: ["xml", "yaml", "json"]
Output: ["json"]
----------------------------------------------------------------------------
Multiplication, division, modulo: `*`, `/`, `%`
----------------------------------------------------------------------------
These infix operators behave as expected when given two numbers.
Division by zero raises an error. `x % y` computes x modulo y.
Multiplying a string by a number produces the concatenation of
that string that many times. `"x" * 0` produces `""`.
Dividing a string by another splits the first using the second
as separators.
Multiplying two objects will merge them recursively: this works
like addition but if both objects contain a value for the
same key, and the values are objects, the two are merged with
the same strategy.
Example: 10 / . * 3
Input: 5
Output: 6
Example: . / ", "
Input: "a, b,c,d, e"
Output: ["a","b,c,d","e"]
Example: {"k": {"a": 1, "b": 2}} * {"k": {"a": 0,"c": 3}}
Input: null
Output: {"k": {"a": 0, "b": 2, "c": 3}}
Example: .[] | (1 / .)?
Input: [1,0,-1]
Output: 1
-1
----------------------------------------------------------------------------
`abs`
----------------------------------------------------------------------------
The builtin function `abs` is defined naively as: `if . < 0 then - . else . end`.
For numeric input, this is the absolute value. See the
section on the identity filter for the implications of this
definition for numeric input.
To compute the absolute value of a number as a floating point number, you may wish use `fabs`.
Example: map(abs)
Input: [-10, -1.1, -1e-1]
Output: [10,1.1,1e-1]
----------------------------------------------------------------------------
`length`
----------------------------------------------------------------------------
The builtin function `length` gets the length of various
different types of value:
- The length of a **string** is the number of Unicode
codepoints it contains (which will be the same as its
JSON-encoded length in bytes if it's pure ASCII).
- The length of a **number** is its absolute value.
- The length of an **array** is the number of elements.
- The length of an **object** is the number of key-value pairs.
- The length of **null** is zero.
- It is an error to use `length` on a **boolean**.
Example: .[] | length
Input: [[1,2], "string", {"a":2}, null, -5]
Output: 2
6
1
0
5
----------------------------------------------------------------------------
`utf8bytelength`
----------------------------------------------------------------------------
The builtin function `utf8bytelength` outputs the number of
bytes used to encode a string in UTF-8.
Example: utf8bytelength
Input: "\u03bc"
Output: 2
----------------------------------------------------------------------------
`keys`, `keys_unsorted`
----------------------------------------------------------------------------
The builtin function `keys`, when given an object, returns
its keys in an array.
The keys are sorted "alphabetically", by unicode codepoint
order. This is not an order that makes particular sense in
any particular language, but you can count on it being the
same for any two objects with the same set of keys,
regardless of locale settings.
When `keys` is given an array, it returns the valid indices
for that array: the integers from 0 to length-1.
The `keys_unsorted` function is just like `keys`, but if
the input is an object then the keys will not be sorted,
instead the keys will roughly be in insertion order.
Example: keys
Input: {"abc": 1, "abcd": 2, "Foo": 3}
Output: ["Foo", "abc", "abcd"]
Example: keys
Input: [42,3,35]
Output: [0,1,2]
----------------------------------------------------------------------------
`has(key)`
----------------------------------------------------------------------------
The builtin function `has` returns whether the input object
has the given key, or the input array has an element at the
given index.
`has($key)` has the same effect as checking whether `$key`
is a member of the array returned by `keys`, although `has`
will be faster.
Example: map(has("foo"))
Input: [{"foo": 42}, {}]
Output: [true, false]
Example: map(has(2))
Input: [[0,1], ["a","b","c"]]
Output: [false, true]
----------------------------------------------------------------------------
`in`
----------------------------------------------------------------------------
The builtin function `in` returns whether or not the input key is in the
given object, or the input index corresponds to an element
in the given array. It is, essentially, an inversed version
of `has`.
Example: .[] | in({"foo": 42})
Input: ["foo", "bar"]
Output: true
false
Example: map(in([0,1]))
Input: [2, 0]
Output: [false, true]
----------------------------------------------------------------------------
`map(f)`, `map_values(f)`
----------------------------------------------------------------------------
For any filter `f`, `map(f)` and `map_values(f)` apply `f`
to each of the values in the input array or object, that is,
to the values of `.[]`.
In the absence of errors, `map(f)` always outputs an array
whereas `map_values(f)` outputs an array if given an array,
or an object if given an object.
When the input to `map_values(f)` is an object, the output
object has the same keys as the input object except for
those keys whose values when piped to `f` produce no values
at all.
The key difference between `map(f)` and `map_values(f)` is
that the former simply forms an array from all the values of
`($x|f)` for each value, `$x`, in the input array or object,
but `map_values(f)` only uses `first($x|f)`.
Specifically, for object inputs, `map_values(f)` constructs
the output object by examining in turn the value of
`first(.[$k]|f)` for each key, `$k`, of the input. If this
expression produces no values, then the corresponding key
will be dropped; otherwise, the output object will have that
value at the key, `$k`.
Here are some examples to clarify the behavior of `map` and
`map_values` when applied to arrays. These examples assume the
input is `[1]` in all cases:
map(.+1) #=> [2]
map(., .) #=> [1,1]
map(empty) #=> []
map_values(.+1) #=> [2]
map_values(., .) #=> [1]
map_values(empty) #=> []
`map(f)` is equivalent to `[.[] | f]` and
`map_values(f)` is equivalent to `.[] |= f`.
In fact, these are their implementations.
Example: map(.+1)
Input: [1,2,3]
Output: [2,3,4]
Example: map_values(.+1)
Input: {"a": 1, "b": 2, "c": 3}
Output: {"a": 2, "b": 3, "c": 4}
Example: map(., .)
Input: [1,2]
Output: [1,1,2,2]
Example: map_values(. // empty)
Input: {"a": null, "b": true, "c": false}
Output: {"b":true}
----------------------------------------------------------------------------
`pick(pathexps)`
----------------------------------------------------------------------------
Emit the projection of the input object or array defined by the
specified sequence of path expressions, such that if `p` is any
one of these specifications, then `(. | p)` will evaluate to the
same value as `(. | pick(pathexps) | p)`. For arrays, negative
indices and `.[m:n]` specifications should not be used.
Example: pick(.a, .b.c, .x)
Input: {"a": 1, "b": {"c": 2, "d": 3}, "e": 4}
Output: {"a":1,"b":{"c":2},"x":null}
Example: pick(.[2], .[0], .[0])
Input: [1,2,3,4]
Output: [1,null,3]
----------------------------------------------------------------------------
`path(path_expression)`
----------------------------------------------------------------------------
Outputs array representations of the given path expression
in `.`. The outputs are arrays of strings (object keys)
and/or numbers (array indices).
Path expressions are jq expressions like `.a`, but also `.[]`.
There are two types of path expressions: ones that can match
exactly, and ones that cannot. For example, `.a.b.c` is an
exact match path expression, while `.a[].b` is not.
`path(exact_path_expression)` will produce the array
representation of the path expression even if it does not
exist in `.`, if `.` is `null` or an array or an object.
`path(pattern)` will produce array representations of the
paths matching `pattern` if the paths exist in `.`.
Note that the path expressions are not different from normal
expressions. The expression
`path(..|select(type=="boolean"))` outputs all the paths to
boolean values in `.`, and only those paths.
Example: path(.a[0].b)
Input: null
Output: ["a",0,"b"]
Example: [path(..)]
Input: {"a":[{"b":1}]}
Output: [[],["a"],["a",0],["a",0,"b"]]
----------------------------------------------------------------------------
`del(path_expression)`
----------------------------------------------------------------------------
The builtin function `del` removes a key and its corresponding
value from an object.
Example: del(.foo)
Input: {"foo": 42, "bar": 9001, "baz": 42}
Output: {"bar": 9001, "baz": 42}
Example: del(.[1, 2])
Input: ["foo", "bar", "baz"]
Output: ["foo"]
----------------------------------------------------------------------------
`getpath(PATHS)`
----------------------------------------------------------------------------
The builtin function `getpath` outputs the values in `.` found
at each path in `PATHS`.
Example: getpath(["a","b"])
Input: null
Output: null
Example: [getpath(["a","b"], ["a","c"])]
Input: {"a":{"b":0, "c":1}}
Output: [0, 1]
----------------------------------------------------------------------------
`setpath(PATHS; VALUE)`
----------------------------------------------------------------------------
The builtin function `setpath` sets the `PATHS` in `.` to `VALUE`.
Example: setpath(["a","b"]; 1)
Input: null
Output: {"a": {"b": 1}}
Example: setpath(["a","b"]; 1)
Input: {"a":{"b":0}}
Output: {"a": {"b": 1}}
Example: setpath([0,"a"]; 1)
Input: null
Output: [{"a":1}]
----------------------------------------------------------------------------
`delpaths(PATHS)`
----------------------------------------------------------------------------
The builtin function `delpaths` deletes the `PATHS` in `.`.
`PATHS` must be an array of paths, where each path is an array
of strings and numbers.
Example: delpaths([["a","b"]])
Input: {"a":{"b":1},"x":{"y":2}}
Output: {"a":{},"x":{"y":2}}
----------------------------------------------------------------------------
`to_entries`, `from_entries`, `with_entries(f)`
----------------------------------------------------------------------------
These functions convert between an object and an array of
key-value pairs. If `to_entries` is passed an object, then
for each `k: v` entry in the input, the output array
includes `{"key": k, "value": v}`.
`from_entries` does the opposite conversion, and `with_entries(f)`
is a shorthand for `to_entries | map(f) | from_entries`, useful for
doing some operation to all keys and values of an object.
`from_entries` accepts `"key"`, `"Key"`, `"name"`, `"Name"`,
`"value"`, and `"Value"` as keys.
Example: to_entries
Input: {"a": 1, "b": 2}
Output: [{"key":"a", "value":1}, {"key":"b", "value":2}]
Example: from_entries
Input: [{"key":"a", "value":1}, {"key":"b", "value":2}]
Output: {"a": 1, "b": 2}
Example: with_entries(.key |= "KEY_" + .)
Input: {"a": 1, "b": 2}
Output: {"KEY_a": 1, "KEY_b": 2}
----------------------------------------------------------------------------
`select(boolean_expression)`
----------------------------------------------------------------------------
The function `select(f)` produces its input unchanged if
`f` returns true for that input, and produces no output
otherwise.
It's useful for filtering lists: `[1,2,3] | map(select(. >= 2))`
will give you `[2,3]`.
Example: map(select(. >= 2))
Input: [1,5,3,0,7]
Output: [5,3,7]
Example: .[] | select(.id == "second")
Input: [{"id": "first", "val": 1}, {"id": "second", "val": 2}]
Output: {"id": "second", "val": 2}
----------------------------------------------------------------------------
`arrays`, `objects`, `iterables`, `booleans`, `numbers`, `normals`, `finites`, `strings`, `nulls`, `values`, `scalars`
----------------------------------------------------------------------------
These built-ins select only inputs that are arrays, objects,
iterables (arrays or objects), booleans, numbers, normal
numbers, finite numbers, strings, null, non-null values, and
non-iterables, respectively.
Example: .[]|numbers
Input: [[],{},1,"foo",null,true,false]
Output: 1
----------------------------------------------------------------------------
`empty`
----------------------------------------------------------------------------
`empty` returns no results. None at all. Not even `null`.
It's useful on occasion. You'll know if you need it :)
Example: 1, empty, 2
Input: null
Output: 1
2
Example: [1,2,empty,3]
Input: null
Output: [1,2,3]
----------------------------------------------------------------------------
`error`, `error(message)`
----------------------------------------------------------------------------
Produces an error with the input value, or with the message
given as the argument. Errors can be caught with try/catch;
see below.
Example: try error catch .
Input: "error message"
Output: "error message"
Example: try error("invalid value: \(.)") catch .
Input: 42
Output: "invalid value: 42"
----------------------------------------------------------------------------
`halt`
----------------------------------------------------------------------------
Stops the jq program with no further outputs. jq will exit
with exit status `0`.
----------------------------------------------------------------------------
`halt_error`, `halt_error(exit_code)`
----------------------------------------------------------------------------
Stops the jq program with no further outputs. The input will
be printed on `stderr` as raw output (i.e., strings will not
have double quotes) with no decoration, not even a newline.
The given `exit_code` (defaulting to `5`) will be jq's exit
status.
For example, `"Error: something went wrong\n"|halt_error(1)`.
----------------------------------------------------------------------------
`$__loc__`
----------------------------------------------------------------------------
Produces an object with a "file" key and a "line" key, with
the filename and line number where `$__loc__` occurs, as
values.
Example: try error("\($__loc__)") catch .
Input: null
Output: "{\"file\":\"<top-level>\",\"line\":1}"
----------------------------------------------------------------------------
`paths`, `paths(node_filter)`
----------------------------------------------------------------------------
`paths` outputs the paths to all the elements in its input
(except it does not output the empty list, representing .
itself).
`paths(f)` outputs the paths to any values for which `f` is `true`.
That is, `paths(type == "number")` outputs the paths to all numeric
values.
Example: [paths]
Input: [1,[[],{"a":2}]]
Output: [[0],[1],[1,0],[1,1],[1,1,"a"]]
Example: [paths(type == "number")]
Input: [1,[[],{"a":2}]]
Output: [[0],[1,1,"a"]]
----------------------------------------------------------------------------
`add`, `add(generator)`
----------------------------------------------------------------------------
The filter `add` takes as input an array, and produces as
output the elements of the array added together. This might
mean summed, concatenated or merged depending on the types
of the elements of the input array - the rules are the same
as those for the `+` operator (described above).
If the input is an empty array, `add` returns `null`.
`add(generator)` operates on the given generator rather than
the input.
Example: add
Input: ["a","b","c"]
Output: "abc"
Example: add
Input: [1, 2, 3]
Output: 6
Example: add
Input: []
Output: null
Example: add(.[].a)
Input: [{"a":3}, {"a":5}, {"b":6}]
Output: 8
----------------------------------------------------------------------------
`any`, `any(condition)`, `any(generator; condition)`
----------------------------------------------------------------------------
The filter `any` takes as input an array of boolean values,
and produces `true` as output if any of the elements of
the array are `true`.
If the input is an empty array, `any` returns `false`.
The `any(condition)` form applies the given condition to the
elements of the input array.
The `any(generator; condition)` form applies the given
condition to all the outputs of the given generator.
Example: any
Input: [true, false]
Output: true
Example: any
Input: [false, false]
Output: false
Example: any
Input: []
Output: false
----------------------------------------------------------------------------
`all`, `all(condition)`, `all(generator; condition)`
----------------------------------------------------------------------------
The filter `all` takes as input an array of boolean values,
and produces `true` as output if all of the elements of
the array are `true`.
The `all(condition)` form applies the given condition to the
elements of the input array.
The `all(generator; condition)` form applies the given
condition to all the outputs of the given generator.
If the input is an empty array, `all` returns `true`.
Example: all
Input: [true, false]
Output: false
Example: all
Input: [true, true]
Output: true
Example: all
Input: []
Output: true
----------------------------------------------------------------------------
`flatten`, `flatten(depth)`
----------------------------------------------------------------------------
The filter `flatten` takes as input an array of nested arrays,
and produces a flat array in which all arrays inside the original
array have been recursively replaced by their values. You can pass
an argument to it to specify how many levels of nesting to flatten.
`flatten(2)` is like `flatten`, but going only up to two
levels deep.
Example: flatten
Input: [1, [2], [[3]]]
Output: [1, 2, 3]
Example: flatten(1)
Input: [1, [2], [[3]]]
Output: [1, 2, [3]]
Example: flatten
Input: [[]]
Output: []
Example: flatten
Input: [{"foo": "bar"}, [{"foo": "baz"}]]
Output: [{"foo": "bar"}, {"foo": "baz"}]
----------------------------------------------------------------------------
`range(upto)`, `range(from; upto)`, `range(from; upto; by)`
----------------------------------------------------------------------------
The `range` function produces a range of numbers. `range(4; 10)`
produces 6 numbers, from 4 (inclusive) to 10 (exclusive). The numbers
are produced as separate outputs. Use `[range(4; 10)]` to get a range as
an array.
The one argument form generates numbers from 0 to the given
number, with an increment of 1.
The two argument form generates numbers from `from` to `upto`
with an increment of 1.
The three argument form generates numbers `from` to `upto`
with an increment of `by`.
Example: range(2; 4)
Input: null
Output: 2
3
Example: [range(2; 4)]
Input: null
Output: [2,3]
Example: [range(4)]
Input: null
Output: [0,1,2,3]
Example: [range(0; 10; 3)]
Input: null
Output: [0,3,6,9]
Example: [range(0; 10; -1)]
Input: null
Output: []
Example: [range(0; -5; -1)]
Input: null
Output: [0,-1,-2,-3,-4]
----------------------------------------------------------------------------
`floor`
----------------------------------------------------------------------------
The `floor` function returns the floor of its numeric input.
Example: floor
Input: 3.14159
Output: 3
----------------------------------------------------------------------------
`sqrt`
----------------------------------------------------------------------------
The `sqrt` function returns the square root of its numeric input.
Example: sqrt
Input: 9
Output: 3
----------------------------------------------------------------------------
`tonumber`
----------------------------------------------------------------------------
The `tonumber` function parses its input as a number. It
will convert correctly-formatted strings to their numeric
equivalent, leave numbers alone, and give an error on all other input.
Example: .[] | tonumber
Input: [1, "1"]
Output: 1
1
----------------------------------------------------------------------------
`toboolean`
----------------------------------------------------------------------------
The `toboolean` function parses its input as a boolean. It
will convert correctly-formatted strings to their boolean
equivalent, leave booleans alone, and give an error on all other input.
Example: .[] | toboolean
Input: ["true", "false", true, false]
Output: true
false
true
false
----------------------------------------------------------------------------
`tostring`
----------------------------------------------------------------------------
The `tostring` function prints its input as a
string. Strings are left unchanged, and all other values are
JSON-encoded.
Example: .[] | tostring
Input: [1, "1", [1]]
Output: "1"
"1"
"[1]"
----------------------------------------------------------------------------
`type`
----------------------------------------------------------------------------
The `type` function returns the type of its argument as a
string, which is one of null, boolean, number, string, array
or object.
Example: map(type)
Input: [0, false, [], {}, null, "hello"]
Output: ["number", "boolean", "array", "object", "null", "string"]
----------------------------------------------------------------------------
`infinite`, `nan`, `isinfinite`, `isnan`, `isfinite`, `isnormal`
----------------------------------------------------------------------------
Some arithmetic operations can yield infinities and "not a
number" (NaN) values. The `isinfinite` builtin returns `true`
if its input is infinite. The `isnan` builtin returns `true`
if its input is a NaN. The `infinite` builtin returns a
positive infinite value. The `nan` builtin returns a NaN.
The `isnormal` builtin returns true if its input is a normal
number.
Note that division by zero raises an error.
Currently most arithmetic operations operating on infinities,
NaNs, and sub-normals do not raise errors.
Example: .[] | (infinite * .) < 0
Input: [-1, 1]
Output: true
false
Example: infinite, nan | type
Input: null
Output: "number"
"number"
----------------------------------------------------------------------------
`sort`, `sort_by(path_expression)`
----------------------------------------------------------------------------
The `sort` functions sorts its input, which must be an
array. Values are sorted in the following order:
* `null`
* `false`
* `true`
* numbers
* strings, in alphabetical order (by unicode codepoint value)
* arrays, in lexical order
* objects
The ordering for objects is a little complex: first they're
compared by comparing their sets of keys (as arrays in
sorted order), and if their keys are equal then the values
are compared key by key.
`sort_by` may be used to sort by a particular field of an
object, or by applying any jq filter. `sort_by(f)` compares
two elements by comparing the result of `f` on each element.
When `f` produces multiple values, it firstly compares the
first values, and the second values if the first values are
equal, and so on.
Example: sort
Input: [8,3,null,6]
Output: [null,3,6,8]
Example: sort_by(.foo)
Input: [{"foo":4, "bar":10}, {"foo":3, "bar":10}, {"foo":2, "bar":1}]
Output: [{"foo":2, "bar":1}, {"foo":3, "bar":10}, {"foo":4, "bar":10}]
Example: sort_by(.foo, .bar)
Input: [{"foo":4, "bar":10}, {"foo":3, "bar":20}, {"foo":2, "bar":1}, {"foo":3, "bar":10}]
Output: [{"foo":2, "bar":1}, {"foo":3, "bar":10}, {"foo":3, "bar":20}, {"foo":4, "bar":10}]
----------------------------------------------------------------------------
`group_by(path_expression)`
----------------------------------------------------------------------------
`group_by(.foo)` takes as input an array, groups the
elements having the same `.foo` field into separate arrays,
and produces all of these arrays as elements of a larger
array, sorted by the value of the `.foo` field.
Any jq expression, not just a field access, may be used in
place of `.foo`. The sorting order is the same as described
in the `sort` function above.
Example: group_by(.foo)
Input: [{"foo":1, "bar":10}, {"foo":3, "bar":100}, {"foo":1, "bar":1}]
Output: [[{"foo":1, "bar":10}, {"foo":1, "bar":1}], [{"foo":3, "bar":100}]]
----------------------------------------------------------------------------
`min`, `max`, `min_by(path_exp)`, `max_by(path_exp)`
----------------------------------------------------------------------------
Find the minimum or maximum element of the input array.
The `min_by(path_exp)` and `max_by(path_exp)` functions allow
you to specify a particular field or property to examine, e.g.
`min_by(.foo)` finds the object with the smallest `foo` field.
Example: min
Input: [5,4,2,7]
Output: 2
Example: max_by(.foo)
Input: [{"foo":1, "bar":14}, {"foo":2, "bar":3}]
Output: {"foo":2, "bar":3}
----------------------------------------------------------------------------
`unique`, `unique_by(path_exp)`
----------------------------------------------------------------------------
The `unique` function takes as input an array and produces
an array of the same elements, in sorted order, with
duplicates removed.
The `unique_by(path_exp)` function will keep only one element
for each value obtained by applying the argument. Think of it
as making an array by taking one element out of every group
produced by `group`.
Example: unique
Input: [1,2,5,3,5,3,1,3]
Output: [1,2,3,5]
Example: unique_by(.foo)
Input: [{"foo": 1, "bar": 2}, {"foo": 1, "bar": 3}, {"foo": 4, "bar": 5}]
Output: [{"foo": 1, "bar": 2}, {"foo": 4, "bar": 5}]
Example: unique_by(length)
Input: ["chunky", "bacon", "kitten", "cicada", "asparagus"]
Output: ["bacon", "chunky", "asparagus"]
----------------------------------------------------------------------------
`reverse`
----------------------------------------------------------------------------
This function reverses an array.
Example: reverse
Input: [1,2,3,4]
Output: [4,3,2,1]
----------------------------------------------------------------------------
`contains(element)`
----------------------------------------------------------------------------
The filter `contains(b)` will produce true if b is
completely contained within the input. A string B is
contained in a string A if B is a substring of A. An array B
is contained in an array A if all elements in B are
contained in any element in A. An object B is contained in
object A if all of the values in B are contained in the
value in A with the same key. All other types are assumed to
be contained in each other if they are equal.
Example: contains("bar")
Input: "foobar"
Output: true
Example: contains(["baz", "bar"])
Input: ["foobar", "foobaz", "blarp"]
Output: true
Example: contains(["bazzzzz", "bar"])
Input: ["foobar", "foobaz", "blarp"]
Output: false
Example: contains({foo: 12, bar: [{barp: 12}]})
Input: {"foo": 12, "bar":[1,2,{"barp":12, "blip":13}]}
Output: true
Example: contains({foo: 12, bar: [{barp: 15}]})
Input: {"foo": 12, "bar":[1,2,{"barp":12, "blip":13}]}
Output: false
----------------------------------------------------------------------------
`indices(s)`
----------------------------------------------------------------------------
Outputs an array containing the indices in `.` where `s`
occurs. The input may be an array, in which case if `s` is an
array then the indices output will be those where all elements
in `.` match those of `s`.
Example: indices(", ")
Input: "a,b, cd, efg, hijk"
Output: [3,7,12]
Example: indices(1)
Input: [0,1,2,1,3,1,4]
Output: [1,3,5]
Example: indices([1,2])
Input: [0,1,2,3,1,4,2,5,1,2,6,7]
Output: [1,8]
----------------------------------------------------------------------------
`index(s)`, `rindex(s)`
----------------------------------------------------------------------------
Outputs the index of the first (`index`) or last (`rindex`)
occurrence of `s` in the input.
Example: index(", ")
Input: "a,b, cd, efg, hijk"
Output: 3
Example: index(1)
Input: [0,1,2,1,3,1,4]
Output: 1
Example: index([1,2])
Input: [0,1,2,3,1,4,2,5,1,2,6,7]
Output: 1
Example: rindex(", ")
Input: "a,b, cd, efg, hijk"
Output: 12
Example: rindex(1)
Input: [0,1,2,1,3,1,4]
Output: 5
Example: rindex([1,2])
Input: [0,1,2,3,1,4,2,5,1,2,6,7]
Output: 8
----------------------------------------------------------------------------
`inside`
----------------------------------------------------------------------------
The filter `inside(b)` will produce true if the input is
completely contained within b. It is, essentially, an
inversed version of `contains`.
Example: inside("foobar")
Input: "bar"
Output: true
Example: inside(["foobar", "foobaz", "blarp"])
Input: ["baz", "bar"]
Output: true
Example: inside(["foobar", "foobaz", "blarp"])
Input: ["bazzzzz", "bar"]
Output: false
Example: inside({"foo": 12, "bar":[1,2,{"barp":12, "blip":13}]})
Input: {"foo": 12, "bar": [{"barp": 12}]}
Output: true
Example: inside({"foo": 12, "bar":[1,2,{"barp":12, "blip":13}]})
Input: {"foo": 12, "bar": [{"barp": 15}]}
Output: false
----------------------------------------------------------------------------
`startswith(str)`
----------------------------------------------------------------------------
Outputs `true` if . starts with the given string argument.
Example: [.[]|startswith("foo")]
Input: ["fo", "foo", "barfoo", "foobar", "barfoob"]
Output: [false, true, false, true, false]
----------------------------------------------------------------------------
`endswith(str)`
----------------------------------------------------------------------------
Outputs `true` if . ends with the given string argument.
Example: [.[]|endswith("foo")]
Input: ["foobar", "barfoo"]
Output: [false, true]
----------------------------------------------------------------------------
`combinations`, `combinations(n)`
----------------------------------------------------------------------------
Outputs all combinations of the elements of the arrays in the
input array. If given an argument `n`, it outputs all combinations
of `n` repetitions of the input array.
Example: combinations
Input: [[1,2], [3, 4]]
Output: [1, 3]
[1, 4]
[2, 3]
[2, 4]
Example: combinations(2)
Input: [0, 1]
Output: [0, 0]
[0, 1]
[1, 0]
[1, 1]
----------------------------------------------------------------------------
`ltrimstr(str)`
----------------------------------------------------------------------------
Outputs its input with the given prefix string removed, if it
starts with it.
Example: [.[]|ltrimstr("foo")]
Input: ["fo", "foo", "barfoo", "foobar", "afoo"]
Output: ["fo","","barfoo","bar","afoo"]
----------------------------------------------------------------------------
`rtrimstr(str)`
----------------------------------------------------------------------------
Outputs its input with the given suffix string removed, if it
ends with it.
Example: [.[]|rtrimstr("foo")]
Input: ["fo", "foo", "barfoo", "foobar", "foob"]
Output: ["fo","","bar","foobar","foob"]
----------------------------------------------------------------------------
`trimstr(str)`
----------------------------------------------------------------------------
Outputs its input with the given string removed at both ends, if it
starts or ends with it.
Example: [.[]|trimstr("foo")]
Input: ["fo", "foo", "barfoo", "foobarfoo", "foob"]
Output: ["fo","","bar","bar","b"]
----------------------------------------------------------------------------
`trim`, `ltrim`, `rtrim`
----------------------------------------------------------------------------
`trim` trims both leading and trailing whitespace.
`ltrim` trims only leading (left side) whitespace.
`rtrim` trims only trailing (right side) whitespace.
Whitespace characters are the usual `" "`, `"\n"` `"\t"`, `"\r"`
and also all characters in the Unicode character database with the
whitespace property. Note that what considers whitespace might
change in the future.
Example: trim, ltrim, rtrim
Input: " abc "
Output: "abc"
"abc "
" abc"
----------------------------------------------------------------------------
`explode`
----------------------------------------------------------------------------
Converts an input string into an array of the string's
codepoint numbers.
Example: explode
Input: "foobar"
Output: [102,111,111,98,97,114]
----------------------------------------------------------------------------
`implode`
----------------------------------------------------------------------------
The inverse of explode.
Example: implode
Input: [65, 66, 67]
Output: "ABC"
----------------------------------------------------------------------------
`split(str)`
----------------------------------------------------------------------------
Splits an input string on the separator argument.
`split` can also split on regex matches when called with
two arguments (see the regular expressions section below).
Example: split(", ")
Input: "a, b,c,d, e, "
Output: ["a","b,c,d","e",""]
----------------------------------------------------------------------------
`join(str)`
----------------------------------------------------------------------------
Joins the array of elements given as input, using the
argument as separator. It is the inverse of `split`: that is,
running `split("foo") | join("foo")` over any input string
returns said input string.
Numbers and booleans in the input are converted to strings.
Null values are treated as empty strings. Arrays and objects
in the input are not supported.
Example: join(", ")
Input: ["a","b,c,d","e"]
Output: "a, b,c,d, e"
Example: join(" ")
Input: ["a",1,2.3,true,null,false]
Output: "a 1 2.3 true false"
----------------------------------------------------------------------------
`ascii_downcase`, `ascii_upcase`
----------------------------------------------------------------------------
Emit a copy of the input string with its alphabetic characters (a-z and A-Z)
converted to the specified case.
Example: ascii_upcase
Input: "useful but not for é"
Output: "USEFUL BUT NOT FOR é"
----------------------------------------------------------------------------
`while(cond; update)`
----------------------------------------------------------------------------
The `while(cond; update)` function allows you to repeatedly
apply an update to `.` until `cond` is false.
Note that `while(cond; update)` is internally defined as a
recursive jq function. Recursive calls within `while` will
not consume additional memory if `update` produces at most one
output for each input. See advanced topics below.
Example: [while(.<100; .*2)]
Input: 1
Output: [1,2,4,8,16,32,64]
----------------------------------------------------------------------------
`repeat(exp)`
----------------------------------------------------------------------------
The `repeat(exp)` function allows you to repeatedly
apply expression `exp` to `.` until an error is raised.
Note that `repeat(exp)` is internally defined as a
recursive jq function. Recursive calls within `repeat` will
not consume additional memory if `exp` produces at most one
output for each input. See advanced topics below.
Example: [repeat(.*2, error)?]
Input: 1
Output: [2]
----------------------------------------------------------------------------
`until(cond; next)`
----------------------------------------------------------------------------
The `until(cond; next)` function allows you to repeatedly
apply the expression `next`, initially to `.` then to its own
output, until `cond` is true. For example, this can be used
to implement a factorial function (see below).
Note that `until(cond; next)` is internally defined as a
recursive jq function. Recursive calls within `until()` will
not consume additional memory if `next` produces at most one
output for each input. See advanced topics below.
Example: [.,1]|until(.[0] < 1; [.[0] - 1, .[1] * .[0]])|.[1]
Input: 4
Output: 24
----------------------------------------------------------------------------
`recurse(f)`, `recurse`, `recurse(f; condition)`
----------------------------------------------------------------------------
The `recurse(f)` function allows you to search through a
recursive structure, and extract interesting data from all
levels. Suppose your input represents a filesystem:
{"name": "/", "children": [
{"name": "/bin", "children": [
{"name": "/bin/ls", "children": []},
{"name": "/bin/sh", "children": []}]},
{"name": "/home", "children": [
{"name": "/home/stephen", "children": [
{"name": "/home/stephen/jq", "children": []}]}]}]}
Now suppose you want to extract all of the filenames
present. You need to retrieve `.name`, `.children[].name`,
`.children[].children[].name`, and so on. You can do this
with:
recurse(.children[]) | .name
When called without an argument, `recurse` is equivalent to
`recurse(.[]?)`.
`recurse(f)` is identical to `recurse(f; true)` and can be
used without concerns about recursion depth.
`recurse(f; condition)` is a generator which begins by
emitting . and then emits in turn .|f, .|f|f, .|f|f|f, ... so long
as the computed value satisfies the condition. For example,
to generate all the integers, at least in principle, one
could write `recurse(.+1; true)`.
The recursive calls in `recurse` will not consume additional
memory whenever `f` produces at most a single output for each
input.
Example: recurse(.foo[])
Input: {"foo":[{"foo": []}, {"foo":[{"foo":[]}]}]}
Output: {"foo":[{"foo":[]},{"foo":[{"foo":[]}]}]}
{"foo":[]}
{"foo":[{"foo":[]}]}
{"foo":[]}
Example: recurse
Input: {"a":0,"b":[1]}
Output: {"a":0,"b":[1]}
0
[1]
1
Example: recurse(. * .; . < 20)
Input: 2
Output: 2
4
16
----------------------------------------------------------------------------
`walk(f)`
----------------------------------------------------------------------------
The `walk(f)` function applies f recursively to every
component of the input entity. When an array is
encountered, f is first applied to its elements and then to
the array itself; when an object is encountered, f is first
applied to all the values and then to the object. In
practice, f will usually test the type of its input, as
illustrated in the following examples. The first example
highlights the usefulness of processing the elements of an
array of arrays before processing the array itself. The second
example shows how all the keys of all the objects within the
input can be considered for alteration.
Example: walk(if type == "array" then sort else . end)
Input: [[4, 1, 7], [8, 5, 2], [3, 6, 9]]
Output: [[1,4,7],[2,5,8],[3,6,9]]
Example: walk( if type == "object" then with_entries( .key |= sub( "^_+"; "") ) else . end )
Input: [ { "_a": { "__b": 2 } } ]
Output: [{"a":{"b":2}}]
----------------------------------------------------------------------------
`have_literal_numbers`
----------------------------------------------------------------------------
This builtin returns true if jq's build configuration
includes support for preservation of input number literals.
----------------------------------------------------------------------------
`have_decnum`
----------------------------------------------------------------------------
This builtin returns true if jq was built with "decnum",
which is the current literal number preserving numeric
backend implementation for jq.
----------------------------------------------------------------------------
`$JQ_BUILD_CONFIGURATION`
----------------------------------------------------------------------------
This builtin binding shows the jq executable's build
configuration. Its value has no particular format, but
it can be expected to be at least the `./configure`
command-line arguments, and may be enriched in the
future to include the version strings for the build
tooling used.
Note that this can be overridden in the command-line
with `--arg` and related options.
----------------------------------------------------------------------------
`$ENV`, `env`
----------------------------------------------------------------------------
`$ENV` is an object representing the environment variables as
set when the jq program started.
`env` outputs an object representing jq's current environment.
At the moment there is no builtin for setting environment
variables.
Example: $ENV.PAGER
Input: null
Output: "less"
Example: env.PAGER
Input: null
Output: "less"
----------------------------------------------------------------------------
`transpose`
----------------------------------------------------------------------------
Transpose a possibly jagged matrix (an array of arrays).
Rows are padded with nulls so the result is always rectangular.
Example: transpose
Input: [[1], [2,3]]
Output: [[1,2],[null,3]]
----------------------------------------------------------------------------
`bsearch(x)`
----------------------------------------------------------------------------
`bsearch(x)` conducts a binary search for x in the input
array. If the input is sorted and contains x, then
`bsearch(x)` will return its index in the array; otherwise, if
the array is sorted, it will return (-1 - ix) where ix is an
insertion point such that the array would still be sorted
after the insertion of x at ix. If the array is not sorted,
`bsearch(x)` will return an integer that is probably of no
interest.
Example: bsearch(0)
Input: [0,1]
Output: 0
Example: bsearch(0)
Input: [1,2,3]
Output: -1
Example: bsearch(4) as $ix | if $ix < 0 then .[-(1+$ix)] = 4 else . end
Input: [1,2,3]
Output: [1,2,3,4]
----------------------------------------------------------------------------
String interpolation: `\(exp)`
----------------------------------------------------------------------------
Inside a string, you can put an expression inside parens
after a backslash. Whatever the expression returns will be
interpolated into the string.
Example: "The input was \(.), which is one less than \(.+1)"
Input: 42
Output: "The input was 42, which is one less than 43"
----------------------------------------------------------------------------
Convert to/from JSON
----------------------------------------------------------------------------
The `tojson` and `fromjson` builtins dump values as JSON texts
or parse JSON texts into values, respectively. The `tojson`
builtin differs from `tostring` in that `tostring` returns strings
unmodified, while `tojson` encodes strings as JSON strings.
Example: [.[]|tostring]
Input: [1, "foo", ["foo"]]
Output: ["1","foo","[\"foo\"]"]
Example: [.[]|tojson]
Input: [1, "foo", ["foo"]]
Output: ["1","\"foo\"","[\"foo\"]"]
Example: [.[]|tojson|fromjson]
Input: [1, "foo", ["foo"]]
Output: [1,"foo",["foo"]]
----------------------------------------------------------------------------
Format strings and escaping
----------------------------------------------------------------------------
The `@foo` syntax is used to format and escape strings,
which is useful for building URLs, documents in a language
like HTML or XML, and so forth. `@foo` can be used as a
filter on its own, the possible escapings are:
* `@text`:
Calls `tostring`, see that function for details.
* `@json`:
Serializes the input as JSON.
* `@html`:
Applies HTML/XML escaping, by mapping the characters
`<>&'"` to their entity equivalents `<`, `>`,
`&`, `'`, `"`.
* `@uri`:
Applies percent-encoding, by mapping all reserved URI
characters to a `%XX` sequence.
* `@urid`:
The inverse of `@uri`, applies percent-decoding, by mapping
all `%XX` sequences to their corresponding URI characters.
* `@csv`:
The input must be an array, and it is rendered as CSV
with double quotes for strings, and quotes escaped by
repetition.
* `@tsv`:
The input must be an array, and it is rendered as TSV
(tab-separated values). Each input array will be printed as
a single line. Fields are separated by a single
tab (ascii `0x09`). Input characters line-feed (ascii `0x0a`),
carriage-return (ascii `0x0d`), tab (ascii `0x09`) and
backslash (ascii `0x5c`) will be output as escape sequences
`\n`, `\r`, `\t`, `\\` respectively.
* `@sh`:
The input is escaped suitable for use in a command-line
for a POSIX shell. If the input is an array, the output
will be a series of space-separated strings.
* `@base64`:
The input is converted to base64 as specified by RFC 4648.
* `@base64d`:
The inverse of `@base64`, input is decoded as specified by RFC 4648.
Note\: If the decoded string is not UTF-8, the results are undefined.
This syntax can be combined with string interpolation in a
useful way. You can follow a `@foo` token with a string
literal. The contents of the string literal will *not* be
escaped. However, all interpolations made inside that string
literal will be escaped. For instance,
@uri "https://www.google.com/search?q=\(.search)"
will produce the following output for the input
`{"search":"what is jq?"}`:
"https://www.google.com/search?q=what%20is%20jq%3F"
Note that the slashes, question mark, etc. in the URL are
not escaped, as they were part of the string literal.
Example: @html
Input: "This works if x < y"
Output: "This works if x < y"
Example: @sh "echo \(.)"
Input: "O'Hara's Ale"
Output: "echo 'O'\\''Hara'\\''s Ale'"
Example: @base64
Input: "This is a message"
Output: "VGhpcyBpcyBhIG1lc3NhZ2U="
Example: @base64d
Input: "VGhpcyBpcyBhIG1lc3NhZ2U="
Output: "This is a message"
----------------------------------------------------------------------------
Dates
----------------------------------------------------------------------------
jq provides some basic date handling functionality, with some
high-level and low-level builtins. In all cases these
builtins deal exclusively with time in UTC.
The `fromdateiso8601` builtin parses datetimes in the ISO 8601
format to a number of seconds since the Unix epoch
(1970-01-01T00:00:00Z). The `todateiso8601` builtin does the
inverse.
The `fromdate` builtin parses datetime strings. Currently
`fromdate` only supports ISO 8601 datetime strings, but in the
future it will attempt to parse datetime strings in more
formats.
The `todate` builtin is an alias for `todateiso8601`.
The `now` builtin outputs the current time, in seconds since
the Unix epoch.
Low-level jq interfaces to the C-library time functions are
also provided: `strptime`, `strftime`, `strflocaltime`,
`mktime`, `gmtime`, and `localtime`. Refer to your host
operating system's documentation for the format strings used
by `strptime` and `strftime`. Note: these are not necessarily
stable interfaces in jq, particularly as to their localization
functionality.
The `gmtime` builtin consumes a number of seconds since the
Unix epoch and outputs a "broken down time" representation of
Greenwich Mean Time as an array of numbers representing
(in this order): the year, the month (zero-based), the day of
the month (one-based), the hour of the day, the minute of the
hour, the second of the minute, the day of the week, and the
day of the year -- all one-based unless otherwise stated. The
day of the week number may be wrong on some systems for dates
before March 1st 1900, or after December 31 2099.
The `localtime` builtin works like the `gmtime` builtin, but
using the local timezone setting.
The `mktime` builtin consumes "broken down time"
representations of time output by `gmtime` and `strptime`.
The `strptime(fmt)` builtin parses input strings matching the
`fmt` argument. The output is in the "broken down time"
representation consumed by `mktime` and output by `gmtime`.
The `strftime(fmt)` builtin formats a time (GMT) with the
given format. The `strflocaltime` does the same, but using
the local timezone setting.
The format strings for `strptime` and `strftime` are described
in typical C library documentation. The format string for ISO
8601 datetime is `"%Y-%m-%dT%H:%M:%SZ"`.
jq may not support some or all of this date functionality on
some systems. In particular, the `%u` and `%j` specifiers for
`strptime(fmt)` are not supported on macOS.
Example: fromdate
Input: "2015-03-05T23:51:47Z"
Output: 1425599507
Example: strptime("%Y-%m-%dT%H:%M:%SZ")
Input: "2015-03-05T23:51:47Z"
Output: [2015,2,5,23,51,47,4,63]
Example: strptime("%Y-%m-%dT%H:%M:%SZ")|mktime
Input: "2015-03-05T23:51:47Z"
Output: 1425599507
----------------------------------------------------------------------------
SQL-Style Operators
----------------------------------------------------------------------------
jq provides a few SQL-style operators.
* `INDEX(stream; index_expression)`:
This builtin produces an object whose keys are computed by
the given index expression applied to each value from the
given stream.
* `JOIN($idx; stream; idx_expr; join_expr)`:
This builtin joins the values from the given stream to the
given index. The index's keys are computed by applying the
given index expression to each value from the given stream.
An array of the value in the stream and the corresponding
value from the index is fed to the given join expression to
produce each result.
* `JOIN($idx; stream; idx_expr)`:
Same as `JOIN($idx; stream; idx_expr; .)`.
* `JOIN($idx; idx_expr)`:
This builtin joins the input `.` to the given index, applying
the given index expression to `.` to compute the index key.
The join operation is as described above.
* `IN(s)`:
This builtin outputs `true` if `.` appears in the given
stream, otherwise it outputs `false`.
* `IN(source; s)`:
This builtin outputs `true` if any value in the source stream
appears in the second stream, otherwise it outputs `false`.
----------------------------------------------------------------------------
`builtins`
----------------------------------------------------------------------------
Returns a list of all builtin functions in the format `name/arity`.
Since functions with the same name but different arities are considered
separate functions, `all/0`, `all/1`, and `all/2` would all be present
in the list.
============================================================================
SECTION: Conditionals and Comparisons
============================================================================
----------------------------------------------------------------------------
`==`, `!=`
----------------------------------------------------------------------------
The expression 'a == b' will produce 'true' if the results of evaluating
a and b are equal (that is, if they represent equivalent JSON values) and
'false' otherwise. In particular, strings are never considered equal
to numbers. In checking for the equality of JSON objects, the ordering of keys
is irrelevant. If you're coming from JavaScript, please note that jq's `==` is like
JavaScript's `===`, the "strict equality" operator.
!= is "not equal", and 'a != b' returns the opposite value of 'a == b'
Example: . == false
Input: null
Output: false
Example: . == {"b": {"d": (4 + 1e-20), "c": 3}, "a":1}
Input: {"a":1, "b": {"c": 3, "d": 4}}
Output: true
Example: .[] == 1
Input: [1, 1.0, "1", "banana"]
Output: true
true
false
false
----------------------------------------------------------------------------
if-then-else-end
----------------------------------------------------------------------------
`if A then B else C end` will act the same as `B` if `A`
produces a value other than false or null, but act the same
as `C` otherwise.
`if A then B end` is the same as `if A then B else . end`.
That is, the `else` branch is optional, and if absent is the
same as `.`. This also applies to `elif` with absent ending `else` branch.
Checking for false or null is a simpler notion of
"truthiness" than is found in JavaScript or Python, but it
means that you'll sometimes have to be more explicit about
the condition you want. You can't test whether, e.g. a
string is empty using `if .name then A else B end`; you'll
need something like `if .name == "" then A else B end` instead.
If the condition `A` produces multiple results, then `B` is evaluated
once for each result that is not false or null, and `C` is evaluated
once for each false or null.
More cases can be added to an if using `elif A then B` syntax.
Example: if . == 0 then
"zero"
elif . == 1 then
"one"
else
"many"
end
Input: 2
Output: "many"
----------------------------------------------------------------------------
`>`, `>=`, `<=`, `<`
----------------------------------------------------------------------------
The comparison operators `>`, `>=`, `<=`, `<` return whether
their left argument is greater than, greater than or equal
to, less than or equal to or less than their right argument
(respectively).
The ordering is the same as that described for `sort`, above.
Example: . < 5
Input: 2
Output: true
----------------------------------------------------------------------------
`and`, `or`, `not`
----------------------------------------------------------------------------
jq supports the normal Boolean operators `and`, `or`, `not`.
They have the same standard of truth as if expressions -
`false` and `null` are considered "false values", and
anything else is a "true value".
If an operand of one of these operators produces multiple
results, the operator itself will produce a result for each input.
`not` is in fact a builtin function rather than an operator,
so it is called as a filter to which things can be piped
rather than with special syntax, as in `.foo and .bar |
not`.
These three only produce the values `true` and `false`, and
so are only useful for genuine Boolean operations, rather
than the common Perl/Python/Ruby idiom of
"value_that_may_be_null or default". If you want to use this
form of "or", picking between two values rather than
evaluating a condition, see the `//` operator below.
Example: 42 and "a string"
Input: null
Output: true
Example: (true, false) or false
Input: null
Output: true
false
Example: (true, true) and (true, false)
Input: null
Output: true
false
true
false
Example: [true, false | not]
Input: null
Output: [false, true]
----------------------------------------------------------------------------
Alternative operator: `//`
----------------------------------------------------------------------------
The `//` operator produces all the values of its left-hand
side that are neither `false` nor `null`. If the
left-hand side produces no values other than `false` or
`null`, then `//` produces all the values of its right-hand
side.
A filter of the form `a // b` produces all the results of
`a` that are not `false` or `null`. If `a` produces no
results, or no results other than `false` or `null`, then `a
// b` produces the results of `b`.
This is useful for providing defaults: `.foo // 1` will
evaluate to `1` if there's no `.foo` element in the
input. It's similar to how `or` is sometimes used in Python
(jq's `or` operator is reserved for strictly Boolean
operations).
Note: `some_generator // defaults_here` is not the same
as `some_generator | . // defaults_here`. The latter will
produce default values for all non-`false`, non-`null`
values of the left-hand side, while the former will not.
Precedence rules can make this confusing. For example, in
`false, 1 // 2` the left-hand side of `//` is `1`, not
`false, 1` -- `false, 1 // 2` parses the same way as `false,
(1 // 2)`. In `(false, null, 1) | . // 42` the left-hand
side of `//` is `.`, which always produces just one value,
while in `(false, null, 1) // 42` the left-hand side is a
generator of three values, and since it produces a
value other `false` and `null`, the default `42` is not
produced.
Example: empty // 42
Input: null
Output: 42
Example: .foo // 42
Input: {"foo": 19}
Output: 19
Example: .foo // 42
Input: {}
Output: 42
Example: (false, null, 1) // 42
Input: null
Output: 1
Example: (false, null, 1) | . // 42
Input: null
Output: 42
42
1
----------------------------------------------------------------------------
try-catch
----------------------------------------------------------------------------
Errors can be caught by using `try EXP catch EXP`. The first
expression is executed, and if it fails then the second is
executed with the error message. The output of the handler,
if any, is output as if it had been the output of the
expression to try.
The `try EXP` form uses `empty` as the exception handler.
Example: try .a catch ". is not an object"
Input: true
Output: ". is not an object"
Example: [.[]|try .a]
Input: [{}, true, {"a":1}]
Output: [null, 1]
Example: try error("some exception") catch .
Input: true
Output: "some exception"
----------------------------------------------------------------------------
Breaking out of control structures
----------------------------------------------------------------------------
A convenient use of try/catch is to break out of control
structures like `reduce`, `foreach`, `while`, and so on.
For example:
# Repeat an expression until it raises "break" as an
# error, then stop repeating without re-raising the error.
# But if the error caught is not "break" then re-raise it.
try repeat(exp) catch if .=="break" then empty else error
jq has a syntax for named lexical labels to "break" or "go (back) to":
label $out | ... break $out ...
The `break $label_name` expression will cause the program to
act as though the nearest (to the left) `label $label_name`
produced `empty`.
The relationship between the `break` and corresponding `label`
is lexical: the label has to be "visible" from the break.
To break out of a `reduce`, for example:
label $out | reduce .[] as $item (null; if .==false then break $out else ... end)
The following jq program produces a syntax error:
break $out
because no label `$out` is visible.
----------------------------------------------------------------------------
Error Suppression / Optional Operator: `?`
----------------------------------------------------------------------------
The `?` operator, used as `EXP?`, is shorthand for `try EXP`.
Example: [.[] | .a?]
Input: [{}, true, {"a":1}]
Output: [null, 1]
Example: [.[] | tonumber?]
Input: ["1", "invalid", "3", 4]
Output: [1, 3, 4]
============================================================================
SECTION: Regular expressions
============================================================================
jq uses the
[Oniguruma regular expression library](https://github.com/kkos/oniguruma/blob/master/doc/RE),
as do PHP, TextMate, Sublime Text, etc, so the
description here will focus on jq specifics.
Oniguruma supports several flavors of regular expression, so it is important to know
that jq uses the ["Perl NG" (Perl with named groups)](https://github.com/kkos/oniguruma/blob/master/doc/SYNTAX.md) flavor.
The jq regex filters are defined so that they can be used using
one of these patterns:
STRING | FILTER(REGEX)
STRING | FILTER(REGEX; FLAGS)
STRING | FILTER([REGEX])
STRING | FILTER([REGEX, FLAGS])
where:
* STRING, REGEX, and FLAGS are jq strings and subject to jq string interpolation;
* REGEX, after string interpolation, should be a valid regular expression;
* FILTER is one of `test`, `match`, or `capture`, as described below.
Since REGEX must evaluate to a JSON string, some characters that are needed
to form a regular expression must be escaped. For example, the regular expression
`\s` signifying a whitespace character would be written as `"\\s"`.
FLAGS is a string consisting of one of more of the supported flags:
* `g` - Global search (find all matches, not just the first)
* `i` - Case insensitive search
* `m` - Multi line mode (`.` will match newlines)
* `n` - Ignore empty matches
* `p` - Both s and m modes are enabled
* `s` - Single line mode (`^` -> `\A`, `$` -> `\Z`)
* `l` - Find longest possible matches
* `x` - Extended regex format (ignore whitespace and comments)
To match a whitespace with the `x` flag, use `\s`, e.g.
jq -n '"a b" | test("a\\sb"; "x")'
Note that certain flags may also be specified within REGEX, e.g.
jq -n '("test", "TEst", "teST", "TEST") | test("(?i)te(?-i)st")'
evaluates to: `true`, `true`, `false`, `false`.
----------------------------------------------------------------------------
`test(val)`, `test(regex; flags)`
----------------------------------------------------------------------------
Like `match`, but does not return match objects, only `true` or `false`
for whether or not the regex matches the input.
Example: test("foo")
Input: "foo"
Output: true
Example: .[] | test("a b c # spaces are ignored"; "ix")
Input: ["xabcd", "ABC"]
Output: true
true
----------------------------------------------------------------------------
`match(val)`, `match(regex; flags)`
----------------------------------------------------------------------------
**match** outputs an object for each match it finds. Matches have
the following fields:
* `offset` - offset in UTF-8 codepoints from the beginning of the input
* `length` - length in UTF-8 codepoints of the match
* `string` - the string that it matched
* `captures` - an array of objects representing capturing groups.
Capturing group objects have the following fields:
* `offset` - offset in UTF-8 codepoints from the beginning of the input
* `length` - length in UTF-8 codepoints of this capturing group
* `string` - the string that was captured
* `name` - the name of the capturing group (or `null` if it was unnamed)
Capturing groups that did not match anything return an offset of -1
Example: match("(abc)+"; "g")
Input: "abc abc"
Output: {"offset": 0, "length": 3, "string": "abc", "captures": [{"offset": 0, "length": 3, "string": "abc", "name": null}]}
{"offset": 4, "length": 3, "string": "abc", "captures": [{"offset": 4, "length": 3, "string": "abc", "name": null}]}
Example: match("foo")
Input: "foo bar foo"
Output: {"offset": 0, "length": 3, "string": "foo", "captures": []}
Example: match(["foo", "ig"])
Input: "foo bar FOO"
Output: {"offset": 0, "length": 3, "string": "foo", "captures": []}
{"offset": 8, "length": 3, "string": "FOO", "captures": []}
Example: match("foo (?<bar123>bar)? foo"; "ig")
Input: "foo bar foo foo foo"
Output: {"offset": 0, "length": 11, "string": "foo bar foo", "captures": [{"offset": 4, "length": 3, "string": "bar", "name": "bar123"}]}
{"offset": 12, "length": 8, "string": "foo foo", "captures": [{"offset": -1, "length": 0, "string": null, "name": "bar123"}]}
Example: [ match("."; "g")] | length
Input: "abc"
Output: 3
----------------------------------------------------------------------------
`capture(val)`, `capture(regex; flags)`
----------------------------------------------------------------------------
Collects the named captures in a JSON object, with the name
of each capture as the key, and the matched string as the
corresponding value.
Example: capture("(?<a>[a-z]+)-(?<n>[0-9]+)")
Input: "xyzzy-14"
Output: { "a": "xyzzy", "n": "14" }
----------------------------------------------------------------------------
`scan(regex)`, `scan(regex; flags)`
----------------------------------------------------------------------------
Emit a stream of the non-overlapping substrings of the input
that match the regex in accordance with the flags, if any
have been specified. If there is no match, the stream is empty.
To capture all the matches for each input string, use the idiom
`[ expr ]`, e.g. `[ scan(regex) ]`. If the regex contains capturing
groups, the filter emits a stream of arrays, each of which contains
the captured strings.
Example: scan("c")
Input: "abcdefabc"
Output: "c"
"c"
Example: scan("(a+)(b+)")
Input: "abaabbaaabbb"
Output: ["a","b"]
["aa","bb"]
["aaa","bbb"]
----------------------------------------------------------------------------
`split(regex; flags)`
----------------------------------------------------------------------------
Splits an input string on each regex match.
For backwards compatibility, when called with a single argument,
`split` splits on a string, not a regex.
Example: split(", *"; null)
Input: "ab,cd, ef"
Output: ["ab","cd","ef"]
----------------------------------------------------------------------------
`splits(regex)`, `splits(regex; flags)`
----------------------------------------------------------------------------
These provide the same results as their `split` counterparts,
but as a stream instead of an array.
Example: splits(", *")
Input: "ab,cd, ef, gh"
Output: "ab"
"cd"
"ef"
"gh"
Example: splits(",? *"; "n")
Input: "ab,cd ef, gh"
Output: "ab"
"cd"
"ef"
"gh"
----------------------------------------------------------------------------
`sub(regex; tostring)`, `sub(regex; tostring; flags)`
----------------------------------------------------------------------------
Emit the string obtained by replacing the first match of
regex in the input string with `tostring`, after
interpolation. `tostring` should be a jq string or a stream
of such strings, each of which may contain references to
named captures. The named captures are, in effect, presented
as a JSON object (as constructed by `capture`) to
`tostring`, so a reference to a captured variable named "x"
would take the form: `"\(.x)"`.
Example: sub("[^a-z]*(?<x>[a-z]+)"; "Z\(.x)"; "g")
Input: "123abc456def"
Output: "ZabcZdef"
Example: [sub("(?<a>.)"; "\(.a|ascii_upcase)", "\(.a|ascii_downcase)")]
Input: "aB"
Output: ["AB","aB"]
----------------------------------------------------------------------------
`gsub(regex; tostring)`, `gsub(regex; tostring; flags)`
----------------------------------------------------------------------------
`gsub` is like `sub` but all the non-overlapping occurrences of the regex are
replaced by `tostring`, after interpolation. If the second argument is a stream
of jq strings, then `gsub` will produce a corresponding stream of JSON strings.
Example: gsub("(?<x>.)[^a]*"; "+\(.x)-")
Input: "Abcabc"
Output: "+A-+a-"
Example: [gsub("p"; "a", "b")]
Input: "p"
Output: ["a","b"]
============================================================================
SECTION: Advanced features
============================================================================
Variables are an absolute necessity in most programming languages, but
they're relegated to an "advanced feature" in jq.
In most languages, variables are the only means of passing around
data. If you calculate a value, and you want to use it more than once,
you'll need to store it in a variable. To pass a value to another part
of the program, you'll need that part of the program to define a
variable (as a function parameter, object member, or whatever) in
which to place the data.
It is also possible to define functions in jq, although this is
is a feature whose biggest use is defining jq's standard library
(many jq functions such as `map` and `select` are in fact written
in jq).
jq has reduction operators, which are very powerful but a bit
tricky. Again, these are mostly used internally, to define some
useful bits of jq's standard library.
It may not be obvious at first, but jq is all about generators
(yes, as often found in other languages). Some utilities are
provided to help deal with generators.
Some minimal I/O support (besides reading JSON from standard
input, and writing JSON to standard output) is available.
Finally, there is a module/library system.
----------------------------------------------------------------------------
Variable / Symbolic Binding Operator: `... as $identifier | ...`
----------------------------------------------------------------------------
In jq, all filters have an input and an output, so manual
plumbing is not necessary to pass a value from one part of a program
to the next. Many expressions, for instance `a + b`, pass their input
to two distinct subexpressions (here `a` and `b` are both passed the
same input), so variables aren't usually necessary in order to use a
value twice.
For instance, calculating the average value of an array of numbers
requires a few variables in most languages - at least one to hold the
array, perhaps one for each element or for a loop counter. In jq, it's
simply `add / length` - the `add` expression is given the array and
produces its sum, and the `length` expression is given the array and
produces its length.
So, there's generally a cleaner way to solve most problems in jq than
defining variables. Still, sometimes they do make things easier, so jq
lets you define variables using `expression as $variable`. All
variable names start with `$`. Here's a slightly uglier version of the
array-averaging example:
length as $array_length | add / $array_length
We'll need a more complicated problem to find a situation where using
variables actually makes our lives easier.
Suppose we have an array of blog posts, with "author" and "title"
fields, and another object which is used to map author usernames to
real names. Our input looks like:
{"posts": [{"title": "First post", "author": "anon"},
{"title": "A well-written article", "author": "person1"}],
"realnames": {"anon": "Anonymous Coward",
"person1": "Person McPherson"}}
We want to produce the posts with the author field containing a real
name, as in:
{"title": "First post", "author": "Anonymous Coward"}
{"title": "A well-written article", "author": "Person McPherson"}
We use a variable, `$names`, to store the realnames object, so that we
can refer to it later when looking up author usernames:
.realnames as $names | .posts[] | {title, author: $names[.author]}
The expression `exp as $x | ...` means: for each value of expression
`exp`, run the rest of the pipeline with the entire original input, and
with `$x` set to that value. Thus `as` functions as something of a
foreach loop.
Just as `{foo}` is a handy way of writing `{foo: .foo}`, so
`{$foo}` is a handy way of writing `{foo: $foo}`.
Multiple variables may be declared using a single `as` expression by
providing a pattern that matches the structure of the input
(this is known as "destructuring"):
. as {realnames: $names, posts: [$first, $second]} | ...
The variable declarations in array patterns (e.g., `. as
[$first, $second]`) bind to the elements of the array in from
the element at index zero on up, in order. When there is no
value at the index for an array pattern element, `null` is
bound to that variable.
Variables are scoped over the rest of the expression that defines
them, so
.realnames as $names | (.posts[] | {title, author: $names[.author]})
will work, but
(.realnames as $names | .posts[]) | {title, author: $names[.author]}
won't.
For programming language theorists, it's more accurate to
say that jq variables are lexically-scoped bindings. In
particular there's no way to change the value of a binding;
one can only setup a new binding with the same name, but which
will not be visible where the old one was.
Example: .bar as $x | .foo | . + $x
Input: {"foo":10, "bar":200}
Output: 210
Example: . as $i|[(.*2|. as $i| $i), $i]
Input: 5
Output: [10,5]
Example: . as [$a, $b, {c: $c}] | $a + $b + $c
Input: [2, 3, {"c": 4, "d": 5}]
Output: 9
Example: .[] as [$a, $b] | {a: $a, b: $b}
Input: [[0], [0, 1], [2, 1, 0]]
Output: {"a":0,"b":null}
{"a":0,"b":1}
{"a":2,"b":1}
----------------------------------------------------------------------------
Destructuring Alternative Operator: `?//`
----------------------------------------------------------------------------
The destructuring alternative operator provides a concise mechanism
for destructuring an input that can take one of several forms.
Suppose we have an API that returns a list of resources and events
associated with them, and we want to get the user_id and timestamp of
the first event for each resource. The API (having been clumsily
converted from XML) will only wrap the events in an array if the resource
has multiple events:
{"resources": [{"id": 1, "kind": "widget", "events": {"action": "create", "user_id": 1, "ts": 13}},
{"id": 2, "kind": "widget", "events": [{"action": "create", "user_id": 1, "ts": 14}, {"action": "destroy", "user_id": 1, "ts": 15}]}]}
We can use the destructuring alternative operator to handle this structural change simply:
.resources[] as {$id, $kind, events: {$user_id, $ts}} ?// {$id, $kind, events: [{$user_id, $ts}]} | {$user_id, $kind, $id, $ts}
Or, if we aren't sure if the input is an array of values or an object:
.[] as [$id, $kind, $user_id, $ts] ?// {$id, $kind, $user_id, $ts} | ...
Each alternative need not define all of the same variables, but all named
variables will be available to the subsequent expression. Variables not
matched in the alternative that succeeded will be `null`:
.resources[] as {$id, $kind, events: {$user_id, $ts}} ?// {$id, $kind, events: [{$first_user_id, $first_ts}]} | {$user_id, $first_user_id, $kind, $id, $ts, $first_ts}
Additionally, if the subsequent expression returns an error, the
alternative operator will attempt to try the next binding. Errors
that occur during the final alternative are passed through.
[[3]] | .[] as [$a] ?// [$b] | if $a != null then error("err: \($a)") else {$a,$b} end
Example: .[] as {$a, $b, c: {$d, $e}} ?// {$a, $b, c: [{$d, $e}]} | {$a, $b, $d, $e}
Input: [{"a": 1, "b": 2, "c": {"d": 3, "e": 4}}, {"a": 1, "b": 2, "c": [{"d": 3, "e": 4}]}]
Output: {"a":1,"b":2,"d":3,"e":4}
{"a":1,"b":2,"d":3,"e":4}
Example: .[] as {$a, $b, c: {$d}} ?// {$a, $b, c: [{$e}]} | {$a, $b, $d, $e}
Input: [{"a": 1, "b": 2, "c": {"d": 3, "e": 4}}, {"a": 1, "b": 2, "c": [{"d": 3, "e": 4}]}]
Output: {"a":1,"b":2,"d":3,"e":null}
{"a":1,"b":2,"d":null,"e":4}
Example: .[] as [$a] ?// [$b] | if $a != null then error("err: \($a)") else {$a,$b} end
Input: [[3]]
Output: {"a":null,"b":3}
----------------------------------------------------------------------------
Defining Functions
----------------------------------------------------------------------------
You can give a filter a name using "def" syntax:
def increment: . + 1;
From then on, `increment` is usable as a filter just like a
builtin function (in fact, this is how many of the builtins
are defined). A function may take arguments:
def map(f): [.[] | f];
Arguments are passed as _filters_ (functions with no
arguments), _not_ as values. The same argument may be
referenced multiple times with different inputs (here `f` is
run for each element of the input array). Arguments to a
function work more like callbacks than like value arguments.
This is important to understand. Consider:
def foo(f): f|f;
5|foo(.*2)
The result will be 20 because `f` is `.*2`, and during the
first invocation of `f` `.` will be 5, and the second time it
will be 10 (5 * 2), so the result will be 20. Function
arguments are filters, and filters expect an input when
invoked.
If you want the value-argument behaviour for defining simple
functions, you can just use a variable:
def addvalue(f): f as $f | map(. + $f);
Or use the short-hand:
def addvalue($f): ...;
With either definition, `addvalue(.foo)` will add the current
input's `.foo` field to each element of the array. Do note
that calling `addvalue(.[])` will cause the `map(. + $f)` part
to be evaluated once per value in the value of `.` at the call
site.
Multiple definitions using the same function name are allowed.
Each re-definition replaces the previous one for the same
number of function arguments, but only for references from
functions (or main program) subsequent to the re-definition.
See also the section below on scoping.
Example: def addvalue(f): . + [f]; map(addvalue(.[0]))
Input: [[1,2],[10,20]]
Output: [[1,2,1], [10,20,10]]
Example: def addvalue(f): f as $x | map(. + $x); addvalue(.[0])
Input: [[1,2],[10,20]]
Output: [[1,2,1,2], [10,20,1,2]]
----------------------------------------------------------------------------
Scoping
----------------------------------------------------------------------------
There are two types of symbols in jq: value bindings (a.k.a.,
"variables"), and functions. Both are scoped lexically,
with expressions being able to refer only to symbols that
have been defined "to the left" of them. The only exception
to this rule is that functions can refer to themselves so as
to be able to create recursive functions.
For example, in the following expression there is a binding
which is visible "to the right" of it, `... | .*3 as
$times_three | [. + $times_three] | ...`, but not "to the
left". Consider this expression now, `... | (.*3 as
$times_three | [. + $times_three]) | ...`: here the binding
`$times_three` is _not_ visible past the closing parenthesis.
----------------------------------------------------------------------------
`isempty(exp)`
----------------------------------------------------------------------------
Returns true if `exp` produces no outputs, false otherwise.
Example: isempty(empty)
Input: null
Output: true
Example: isempty(.[])
Input: []
Output: true
Example: isempty(.[])
Input: [1,2,3]
Output: false
----------------------------------------------------------------------------
`limit(n; expr)`
----------------------------------------------------------------------------
The `limit` function extracts up to `n` outputs from `expr`.
Example: [limit(3; .[])]
Input: [0,1,2,3,4,5,6,7,8,9]
Output: [0,1,2]
----------------------------------------------------------------------------
`skip(n; expr)`
----------------------------------------------------------------------------
The `skip` function skips the first `n` outputs from `expr`.
Example: [skip(3; .[])]
Input: [0,1,2,3,4,5,6,7,8,9]
Output: [3,4,5,6,7,8,9]
----------------------------------------------------------------------------
`first(expr)`, `last(expr)`, `nth(n; expr)`
----------------------------------------------------------------------------
The `first(expr)` and `last(expr)` functions extract the first
and last values from `expr`, respectively.
The `nth(n; expr)` function extracts the nth value output by `expr`.
Note that `nth(n; expr)` doesn't support negative values of `n`.
Example: [first(range(.)), last(range(.)), nth(5; range(.))]
Input: 10
Output: [0,9,5]
Example: [first(empty), last(empty), nth(5; empty)]
Input: null
Output: []
----------------------------------------------------------------------------
`first`, `last`, `nth(n)`
----------------------------------------------------------------------------
The `first` and `last` functions extract the first
and last values from any array at `.`.
The `nth(n)` function extracts the nth value of any array at `.`.
Example: [range(.)]|[first, last, nth(5)]
Input: 10
Output: [0,9,5]
----------------------------------------------------------------------------
`reduce`
----------------------------------------------------------------------------
The `reduce` syntax allows you to combine all of the results of
an expression by accumulating them into a single answer.
The form is `reduce EXP as $var (INIT; UPDATE)`.
As an example, we'll pass `[1,2,3]` to this expression:
reduce .[] as $item (0; . + $item)
For each result that `.[]` produces, `. + $item` is run to
accumulate a running total, starting from 0 as the input value.
In this example, `.[]` produces the results `1`, `2`, and `3`,
so the effect is similar to running something like this:
0 | 1 as $item | . + $item |
2 as $item | . + $item |
3 as $item | . + $item
Example: reduce .[] as $item (0; . + $item)
Input: [1,2,3,4,5]
Output: 15
Example: reduce .[] as [$i,$j] (0; . + $i * $j)
Input: [[1,2],[3,4],[5,6]]
Output: 44
Example: reduce .[] as {$x,$y} (null; .x += $x | .y += [$y])
Input: [{"x":"a","y":1},{"x":"b","y":2},{"x":"c","y":3}]
Output: {"x":"abc","y":[1,2,3]}
----------------------------------------------------------------------------
`foreach`
----------------------------------------------------------------------------
The `foreach` syntax is similar to `reduce`, but intended to
allow the construction of `limit` and reducers that produce
intermediate results.
The form is `foreach EXP as $var (INIT; UPDATE; EXTRACT)`.
As an example, we'll pass `[1,2,3]` to this expression:
foreach .[] as $item (0; . + $item; [$item, . * 2])
Like the `reduce` syntax, `. + $item` is run for each result
that `.[]` produces, but `[$item, . * 2]` is run for each
intermediate values. In this example, since the intermediate
values are `1`, `3`, and `6`, the `foreach` expression produces
`[1,2]`, `[2,6]`, and `[3,12]`. So the effect is similar
to running something like this:
0 | 1 as $item | . + $item | [$item, . * 2],
2 as $item | . + $item | [$item, . * 2],
3 as $item | . + $item | [$item, . * 2]
When `EXTRACT` is omitted, the identity filter is used.
That is, it outputs the intermediate values as they are.
Example: foreach .[] as $item (0; . + $item)
Input: [1,2,3,4,5]
Output: 1
3
6
10
15
Example: foreach .[] as $item (0; . + $item; [$item, . * 2])
Input: [1,2,3,4,5]
Output: [1,2]
[2,6]
[3,12]
[4,20]
[5,30]
Example: foreach .[] as $item (0; . + 1; {index: ., $item})
Input: ["foo", "bar", "baz"]
Output: {"index":1,"item":"foo"}
{"index":2,"item":"bar"}
{"index":3,"item":"baz"}
----------------------------------------------------------------------------
Recursion
----------------------------------------------------------------------------
As described above, `recurse` uses recursion, and any jq
function can be recursive. The `while` builtin is also
implemented in terms of recursion.
Tail calls are optimized whenever the expression to the left of
the recursive call outputs its last value. In practice this
means that the expression to the left of the recursive call
should not produce more than one output for each input.
For example:
def recurse(f): def r: ., (f | select(. != null) | r); r;
def while(cond; update):
def _while:
if cond then ., (update | _while) else empty end;
_while;
def repeat(exp):
def _repeat:
exp, _repeat;
_repeat;
----------------------------------------------------------------------------
Generators and iterators
----------------------------------------------------------------------------
Some jq operators and functions are actually generators in
that they can produce zero, one, or more values for each
input, just as one might expect in other programming
languages that have generators. For example, `.[]`
generates all the values in its input (which must be an
array or an object), `range(0; 10)` generates the integers
between 0 and 10, and so on.
Even the comma operator is a generator, generating first
the values generated by the expression to the left of the
comma, then the values generated by the expression on the
right of the comma.
The `empty` builtin is the generator that produces zero
outputs. The `empty` builtin backtracks to the preceding
generator expression.
All jq functions can be generators just by using builtin
generators. It is also possible to construct new generators
using only recursion and the comma operator. If
recursive calls are "in tail position" then the
generator will be efficient. In the example below the
recursive call by `_range` to itself is in tail position.
The example shows off three advanced topics: tail recursion,
generator construction, and sub-functions.
Example: def range(init; upto; by): def _range: if (by > 0 and . < upto) or (by < 0 and . > upto) then ., ((.+by)|_range) else empty end; if init == upto then empty elif by == 0 then init else init|_range end; range(0; 10; 3)
Input: null
Output: 0
3
6
9
Example: def while(cond; update): def _while: if cond then ., (update | _while) else empty end; _while; [while(.<100; .*2)]
Input: 1
Output: [1,2,4,8,16,32,64]
============================================================================
SECTION: Math
============================================================================
jq currently only has IEEE754 double-precision (64-bit) floating
point number support.
Besides simple arithmetic operators such as `+`, jq also has most
standard math functions from the C math library. C math functions
that take a single input argument (e.g., `sin()`) are available as
zero-argument jq functions. C math functions that take two input
arguments (e.g., `pow()`) are available as two-argument jq
functions that ignore `.`. C math functions that take three input
arguments are available as three-argument jq functions that ignore
`.`.
Availability of standard math functions depends on the
availability of the corresponding math functions in your operating
system and C math library. Unavailable math functions will be
defined but will raise an error.
One-input C math functions: `acos` `acosh` `asin` `asinh` `atan`
`atanh` `cbrt` `ceil` `cos` `cosh` `erf` `erfc` `exp` `exp10`
`exp2` `expm1` `fabs` `floor` `gamma` `j0` `j1` `lgamma` `log`
`log10` `log1p` `log2` `logb` `nearbyint` `rint` `round`
`significand` `sin` `sinh` `sqrt` `tan` `tanh` `tgamma` `trunc`
`y0` `y1`.
Two-input C math functions: `atan2` `copysign` `drem` `fdim`
`fmax` `fmin` `fmod` `frexp` `hypot` `jn` `ldexp` `modf`
`nextafter` `nexttoward` `pow` `remainder` `scalb` `scalbln` `yn`.
Three-input C math functions: `fma`.
See your system's manual for more information on each of these.
============================================================================
SECTION: I/O
============================================================================
At this time jq has minimal support for I/O, mostly in the
form of control over when inputs are read. Two builtins functions
are provided for this, `input` and `inputs`, that read from the
same sources (e.g., `stdin`, files named on the command-line) as
jq itself. These two builtins, and jq's own reading actions, can
be interleaved with each other. They are commonly used in combination
with the null input option `-n` to prevent one input from being read
implicitly.
Two builtins provide minimal output capabilities, `debug`, and
`stderr`. (Recall that a jq program's output values are always
output as JSON texts on `stdout`.) The `debug` builtin can have
application-specific behavior, such as for executables that use
the libjq C API but aren't the jq executable itself. The `stderr`
builtin outputs its input in raw mode to stderr with no additional
decoration, not even a newline.
Most jq builtins are referentially transparent, and yield constant
and repeatable value streams when applied to constant inputs.
This is not true of I/O builtins.
----------------------------------------------------------------------------
`input`
----------------------------------------------------------------------------
Outputs one new input.
Note that when using `input` it is generally necessary to
invoke jq with the `-n` command-line option, otherwise
the first entity will be lost.
echo 1 2 3 4 | jq '[., input]' # [1,2] [3,4]
----------------------------------------------------------------------------
`inputs`
----------------------------------------------------------------------------
Outputs all remaining inputs, one by one.
This is primarily useful for reductions over a program's
inputs. Note that when using `inputs` it is generally necessary
to invoke jq with the `-n` command-line option, otherwise
the first entity will be lost.
echo 1 2 3 | jq -n 'reduce inputs as $i (0; . + $i)' # 6
----------------------------------------------------------------------------
`debug`, `debug(msgs)`
----------------------------------------------------------------------------
These two filters are like `.` but have as a side-effect the
production of one or more messages on stderr.
The message produced by the `debug` filter has the form
["DEBUG:",<input-value>]
where `<input-value>` is a compact rendition of the input
value. This format may change in the future.
The `debug(msgs)` filter is defined as `(msgs | debug | empty), .`
thus allowing great flexibility in the content of the message,
while also allowing multi-line debugging statements to be created.
For example, the expression:
1 as $x | 2 | debug("Entering function foo with $x == \($x)", .) | (.+1)
would produce the value 3 but with the following two lines
being written to stderr:
["DEBUG:","Entering function foo with $x == 1"]
["DEBUG:",2]
----------------------------------------------------------------------------
`stderr`
----------------------------------------------------------------------------
Prints its input in raw and compact mode to stderr with no
additional decoration, not even a newline.
----------------------------------------------------------------------------
`input_filename`
----------------------------------------------------------------------------
Returns the name of the file whose input is currently being
filtered. Note that this will not work well unless jq is
running in a UTF-8 locale.
----------------------------------------------------------------------------
`input_line_number`
----------------------------------------------------------------------------
Returns the line number of the input currently being filtered.
============================================================================
SECTION: Streaming
============================================================================
With the `--stream` option jq can parse input texts in a streaming
fashion, allowing jq programs to start processing large JSON texts
immediately rather than after the parse completes. If you have a
single JSON text that is 1GB in size, streaming it will allow you
to process it much more quickly.
However, streaming isn't easy to deal with as the jq program will
have `[<path>, <leaf-value>]` (and a few other forms) as inputs.
Several builtins are provided to make handling streams easier.
The examples below use the streamed form of `["a",["b"]]`, which is
`[[0],"a"],[[1,0],"b"],[[1,0]],[[1]]`.
Streaming forms include `[<path>, <leaf-value>]` (to indicate any
scalar value, empty array, or empty object), and `[<path>]` (to
indicate the end of an array or object). Future versions of jq
run with `--stream` and `--seq` may output additional forms such
as `["error message"]` when an input text fails to parse.
----------------------------------------------------------------------------
`truncate_stream(stream_expression)`
----------------------------------------------------------------------------
Consumes a number as input and truncates the corresponding
number of path elements from the left of the outputs of the
given streaming expression.
Example: truncate_stream([[0],"a"],[[1,0],"b"],[[1,0]],[[1]])
Input: 1
Output: [[0],"b"]
[[0]]
----------------------------------------------------------------------------
`fromstream(stream_expression)`
----------------------------------------------------------------------------
Outputs values corresponding to the stream expression's
outputs.
Example: fromstream(1|truncate_stream([[0],"a"],[[1,0],"b"],[[1,0]],[[1]]))
Input: null
Output: ["b"]
----------------------------------------------------------------------------
`tostream`
----------------------------------------------------------------------------
The `tostream` builtin outputs the streamed form of its input.
Example: . as $dot|fromstream($dot|tostream)|.==$dot
Input: [0,[1,{"a":1},{"b":2}]]
Output: true
============================================================================
SECTION: Assignment
============================================================================
Assignment works a little differently in jq than in most
programming languages. jq doesn't distinguish between references
to and copies of something - two objects or arrays are either
equal or not equal, without any further notion of being "the
same object" or "not the same object".
If an object has two fields which are arrays, `.foo` and `.bar`,
and you append something to `.foo`, then `.bar` will not get
bigger, even if you've previously set `.bar = .foo`. If you're
used to programming in languages like Python, Java, Ruby,
JavaScript, etc. then you can think of it as though jq does a full
deep copy of every object before it does the assignment (for
performance it doesn't actually do that, but that's the general
idea).
This means that it's impossible to build circular values in jq
(such as an array whose first element is itself). This is quite
intentional, and ensures that anything a jq program can produce
can be represented in JSON.
All the assignment operators in jq have path expressions on the
left-hand side (LHS). The right-hand side (RHS) provides values
to set to the paths named by the LHS path expressions.
Values in jq are always immutable. Internally, assignment works
by using a reduction to compute new, replacement values for `.` that
have had all the desired assignments applied to `.`, then
outputting the modified value. This might be made clear by this
example: `{a:{b:{c:1}}} | (.a.b|=3), .`. This will output
`{"a":{"b":3}}` and `{"a":{"b":{"c":1}}}` because the last
sub-expression, `.`, sees the original value, not the modified
value.
Most users will want to use modification assignment operators,
such as `|=` or `+=`, rather than `=`.
Note that the LHS of assignment operators refers to a value in
`.`. Thus `$var.foo = 1` won't work as expected (`$var.foo` is
not a valid or useful path expression in `.`); use `$var | .foo =
1` instead.
Note too that `.a,.b=0` does not set `.a` and `.b`, but
`(.a,.b)=0` sets both.
----------------------------------------------------------------------------
Update-assignment: `|=`
----------------------------------------------------------------------------
This is the "update" operator `|=`. It takes a filter on the
right-hand side and works out the new value for the property
of `.` being assigned to by running the old value through this
expression. For instance, `(.foo, .bar) |= .+1` will build an
object with the `foo` field set to the input's `foo` plus 1,
and the `bar` field set to the input's `bar` plus 1.
The left-hand side can be any general path expression; see `path()`.
Note that the left-hand side of `|=` refers to a value in `.`.
Thus `$var.foo |= . + 1` won't work as expected (`$var.foo` is
not a valid or useful path expression in `.`); use `$var |
.foo |= . + 1` instead.
If the right-hand side outputs no values (i.e., `empty`), then
the left-hand side path will be deleted, as with `del(path)`.
If the right-hand side outputs multiple values, only the first
one will be used (COMPATIBILITY NOTE: in jq 1.5 and earlier
releases, it used to be that only the last one was used).
Example: (..|select(type=="boolean")) |= if . then 1 else 0 end
Input: [true,false,[5,true,[true,[false]],false]]
Output: [1,0,[5,1,[1,[0]],0]]
----------------------------------------------------------------------------
Arithmetic update-assignment: `+=`, `-=`, `*=`, `/=`, `%=`, `//=`
----------------------------------------------------------------------------
jq has a few operators of the form `a op= b`, which are all
equivalent to `a |= . op b`. So, `+= 1` can be used to
increment values, being the same as `|= . + 1`.
Example: .foo += 1
Input: {"foo": 42}
Output: {"foo": 43}
----------------------------------------------------------------------------
Plain assignment: `=`
----------------------------------------------------------------------------
This is the plain assignment operator. Unlike the others, the
input to the right-hand side (RHS) is the same as the input to
the left-hand side (LHS) rather than the value at the LHS
path, and all values output by the RHS will be used (as shown
below).
If the RHS of `=` produces multiple values, then for each such
value jq will set the paths on the left-hand side to the value
and then it will output the modified `.`. For example,
`(.a,.b) = range(2)` outputs `{"a":0,"b":0}`, then
`{"a":1,"b":1}`. The "update" assignment forms (see above) do
not do this.
This example should show the difference between `=` and `|=`:
Provide input `{"a": {"b": 10}, "b": 20}` to the programs
.a = .b
and
.a |= .b
The former will set the `a` field of the input to the `b`
field of the input, and produce the output `{"a": 20, "b": 20}`.
The latter will set the `a` field of the input to the `a`
field's `b` field, producing `{"a": 10, "b": 20}`.
Example: .a = .b
Input: {"a": {"b": 10}, "b": 20}
Output: {"a":20,"b":20}
Example: .a |= .b
Input: {"a": {"b": 10}, "b": 20}
Output: {"a":10,"b":20}
Example: (.a, .b) = range(3)
Input: null
Output: {"a":0,"b":0}
{"a":1,"b":1}
{"a":2,"b":2}
Example: (.a, .b) |= range(3)
Input: null
Output: {"a":0,"b":0}
----------------------------------------------------------------------------
Complex assignments
----------------------------------------------------------------------------
Lots more things are allowed on the left-hand side of a jq assignment
than in most languages. We've already seen simple field accesses on
the left hand side, and it's no surprise that array accesses work just
as well:
.posts[0].title = "JQ Manual"
What may come as a surprise is that the expression on the left may
produce multiple results, referring to different points in the input
document:
.posts[].comments |= . + ["this is great"]
That example appends the string "this is great" to the "comments"
array of each post in the input (where the input is an object with a
field "posts" which is an array of posts).
When jq encounters an assignment like 'a = b', it records the "path"
taken to select a part of the input document while executing a. This
path is then used to find which part of the input to change while
executing the assignment. Any filter may be used on the
left-hand side of an equals - whichever paths it selects from the
input will be where the assignment is performed.
This is a very powerful operation. Suppose we wanted to add a comment
to blog posts, using the same "blog" input above. This time, we only
want to comment on the posts written by "stedolan". We can find those
posts using the "select" function described earlier:
.posts[] | select(.author == "stedolan")
The paths provided by this operation point to each of the posts that
"stedolan" wrote, and we can comment on each of them in the same way
that we did before:
(.posts[] | select(.author == "stedolan") | .comments) |=
. + ["terrible."]
============================================================================
SECTION: Comments
============================================================================
You can write comments in your jq filters using `#`.
A `#` character (not part of a string) starts a comment.
All characters from `#` to the end of the line are ignored.
If the end of the line is preceded by an odd number of backslash
characters, the following line is also considered part of the
comment and is ignored.
For example, the following code outputs `[1,3,4,7]`
[
1,
# foo \
2,
# bar \\
3,
4, # baz \\\
5, \
6,
7
# comment \
comment \
comment
]
Backslash continuing the comment on the next line can be useful
when writing the "shebang" for a jq script:
#!/bin/sh --
# total - Output the sum of the given arguments (or stdin)
# usage: total [numbers...]
# \
exec jq --args -MRnf -- "$0" "$@"
$ARGS.positional |
reduce (
if . == []
then inputs
else .[]
end |
. as $dot |
try tonumber catch false |
if not or isnan then
@json "total: Invalid number \($dot).\n" | halt_error(1)
end
) as $n (0; . + $n)
The `exec` line is considered a comment by jq, so it is ignored.
But it is not ignored by `sh`, since in `sh` a backslash at the
end of the line does not continue the comment.
With this trick, when the script is invoked as `total 1 2`,
`/bin/sh -- /path/to/total 1 2` will be run, and `sh` will then
run `exec jq --args -MRnf -- /path/to/total 1 2` replacing itself
with a `jq` interpreter invoked with the specified options (`-M`,
`-R`, `-n`, `--args`), that evaluates the current file (`$0`),
with the arguments (`$@`) that were passed to `sh`.
============================================================================
SECTION: Modules
============================================================================
jq has a library/module system. Modules are files whose names end
in `.jq`.
Modules imported by a program are searched for in a default search
path (see below). The `import` and `include` directives allow the
importer to alter this path.
Paths in the search path are subject to various substitutions.
For paths starting with `~/`, the user's home directory is
substituted for `~`.
For paths starting with `$ORIGIN/`, the directory where the jq
executable is located is substituted for `$ORIGIN`.
For paths starting with `./` or paths that are `.`, the path of
the including file is substituted for `.`. For top-level programs
given on the command-line, the current directory is used.
Import directives can optionally specify a search path to which
the default is appended.
The default search path is the search path given to the `-L`
command-line option, else `["~/.jq", "$ORIGIN/../lib/jq",
"$ORIGIN/../lib"]`.
Null and empty string path elements terminate search path
processing.
A dependency with relative path `foo/bar` would be searched for in
`foo/bar.jq` and `foo/bar/bar.jq` in the given search path. This
is intended to allow modules to be placed in a directory along
with, for example, version control files, README files, and so on,
but also to allow for single-file modules.
Consecutive components with the same name are not allowed to avoid
ambiguities (e.g., `foo/foo`).
For example, with `-L$HOME/.jq` a module `foo` can be found in
`$HOME/.jq/foo.jq` and `$HOME/.jq/foo/foo.jq`.
If `.jq` exists in the user's home directory, and is a file (not a
directory), it is automatically sourced into the main program.
----------------------------------------------------------------------------
`import RelativePathString as NAME [<metadata>];`
----------------------------------------------------------------------------
Imports a module found at the given path relative to a
directory in a search path. A `.jq` suffix will be added to
the relative path string. The module's symbols are prefixed
with `NAME::`.
The optional metadata must be a constant jq expression. It
should be an object with keys like `homepage` and so on. At
this time jq only uses the `search` key/value of the metadata.
The metadata is also made available to users via the
`modulemeta` builtin.
The `search` key in the metadata, if present, should have a
string or array value (array of strings); this is the search
path to be prefixed to the top-level search path.
----------------------------------------------------------------------------
`include RelativePathString [<metadata>];`
----------------------------------------------------------------------------
Imports a module found at the given path relative to a
directory in a search path as if it were included in place. A
`.jq` suffix will be added to the relative path string. The
module's symbols are imported into the caller's namespace as
if the module's content had been included directly.
The optional metadata must be a constant jq expression. It
should be an object with keys like `homepage` and so on. At
this time jq only uses the `search` key/value of the metadata.
The metadata is also made available to users via the
`modulemeta` builtin.
----------------------------------------------------------------------------
`import RelativePathString as $NAME [<metadata>];`
----------------------------------------------------------------------------
Imports a JSON file found at the given path relative to a
directory in a search path. A `.json` suffix will be added to
the relative path string. The file's data will be available
as `$NAME::NAME`.
The optional metadata must be a constant jq expression. It
should be an object with keys like `homepage` and so on. At
this time jq only uses the `search` key/value of the metadata.
The metadata is also made available to users via the
`modulemeta` builtin.
The `search` key in the metadata, if present, should have a
string or array value (array of strings); this is the search
path to be prefixed to the top-level search path.
----------------------------------------------------------------------------
`module <metadata>;`
----------------------------------------------------------------------------
This directive is entirely optional. It's not required for
proper operation. It serves only the purpose of providing
metadata that can be read with the `modulemeta` builtin.
The metadata must be a constant jq expression. It should be
an object with keys like `homepage`. At this time jq doesn't
use this metadata, but it is made available to users via the
`modulemeta` builtin.
----------------------------------------------------------------------------
`modulemeta`
----------------------------------------------------------------------------
Takes a module name as input and outputs the module's metadata
as an object, with the module's imports (including metadata)
as an array value for the `deps` key and the module's defined
functions as an array value for the `defs` key.
Programs can use this to query a module's metadata, which they
could then use to, for example, search for, download, and
install missing dependencies.</pblock>
<pblock filename="sources/jq.test" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/jq.test">
# Tests are groups of three lines: program, input, expected output
# Blank lines and lines starting with # are ignored
#
# Simple value tests to check parser. Input is irrelevant
#
true
null
true
false
null
false
null
42
null
1
null
1
-1
null
-1
# FIXME: much more number testing needed
{}
null
{}
[]
null
[]
{x:-1},{x:-.},{x:-.|abs}
1
{"x":-1}
{"x":-1}
{"x":1}
# The input line starts with a 0xFEFF (byte order mark) codepoint
# No, there is no reason to have a byte order mark in UTF8 text.
# But apparently people do, so jq shouldn't break on it.
.
"byte order mark"
"byte order mark"
# We test escapes by matching them against Unicode codepoints
# FIXME: more tests needed for weird unicode stuff (e.g. utf16 pairs)
"Aa\r\n\t\b\f\u03bc"
null
"Aa\u000d\u000a\u0009\u0008\u000c\u03bc"
.
"Aa\r\n\t\b\f\u03bc"
"Aa\u000d\u000a\u0009\u0008\u000c\u03bc"
%%FAIL
"u\vw"
jq: error: Invalid escape at line 1, column 4 (while parsing '"\v"') at <top-level>, line 1, column 3:
"u\vw"
^^
"inter\("pol" + "ation")"
null
"interpolation"
@text,@json,([1,.]|@csv,@tsv),@html,(@uri|.,@urid),@sh,(@base64|.,@base64d)
"!()<>&'\"\t"
"!()<>&'\"\t"
"\"!()<>&'\\\"\\t\""
"1,\"!()<>&'\"\"\t\""
"1\t!()<>&'\"\\t"
"!()<>&'"\t"
"%21%28%29%3C%3E%26%27%22%09"
"!()<>&'\"\t"
"'!()<>&'\\''\"\t'"
"ISgpPD4mJyIJ"
"!()<>&'\"\t"
# regression test for #436
@base64
"foóbar\n"
"Zm/Ds2Jhcgo="
@base64d
"Zm/Ds2Jhcgo="
"foóbar\n"
@uri
"\u03bc"
"%CE%BC"
@urid
"%CE%BC"
"\u03bc"
@html "<b>\(.)</b>"
"<script>hax</script>"
"<b><script>hax</script></b>"
[.[]|tojson|fromjson]
["foo", 1, ["a", 1, "b", 2, {"foo":"bar"}]]
["foo",1,["a",1,"b",2,{"foo":"bar"}]]
#
# Dictionary construction syntax
#
{a: 1}
null
{"a":1}
{a,b,(.d):.a,e:.b}
{"a":1, "b":2, "c":3, "d":"c"}
{"a":1, "b":2, "c":1, "e":2}
{"a",b,"a$\(1+1)"}
{"a":1, "b":2, "c":3, "a$2":4}
{"a":1, "b":2, "a$2":4}
%%FAIL
{(0):1}
jq: error: Cannot use number (0) as object key at <top-level>, line 1, column 3:
{(0):1}
^
%%FAIL
{1+2:3}
jq: error: May need parentheses around object key expression at <top-level>, line 1, column 2:
{1+2:3}
^^^
%%FAIL
{non_const:., (0):1}
jq: error: Cannot use number (0) as object key at <top-level>, line 1, column 16:
{non_const:., (0):1}
^
#
# Field access, piping
#
.foo
{"foo": 42, "bar": 43}
42
.foo | .bar
{"foo": {"bar": 42}, "bar": "badvalue"}
42
.foo.bar
{"foo": {"bar": 42}, "bar": "badvalue"}
42
.foo_bar
{"foo_bar": 2}
2
.["foo"].bar
{"foo": {"bar": 42}, "bar": "badvalue"}
42
."foo"."bar"
{"foo": {"bar": 20}}
20
.e0, .E1, .E-1, .E+1
{"e0": 1, "E1": 2, "E": 3}
1
2
2
4
[.[]|.foo?]
[1,[2],{"foo":3,"bar":4},{},{"foo":5}]
[3,null,5]
[.[]|.foo?.bar?]
[1,[2],[],{"foo":3},{"foo":{"bar":4}},{}]
[4,null]
[..]
[1,[[2]],{ "a":[1]}]
[[1,[[2]],{"a":[1]}],1,[[2]],[2],2,{"a":[1]},[1],1]
[.[]|.[]?]
[1,null,[],[1,[2,[[3]]]],[{}],[{"a":[1,[2]]}]]
[1,[2,[[3]]],{},{"a":[1,[2]]}]
[.[]|.[1:3]?]
[1,null,true,false,"abcdef",{},{"a":1,"b":2},[],[1,2,3,4,5],[1,2]]
[null,"bc",[],[2,3],[2]]
# chaining/suffix-list, with and without dot
map(try .a[] catch ., try .a.[] catch ., .a[]?, .a.[]?)
[{"a": [1,2]}, {"a": 123}]
[1,2,1,2,1,2,1,2,"Cannot iterate over number (123)","Cannot iterate over number (123)"]
# oss-fuzz #66070: objects[] leaks if a non-last element throws an error
try ["OK", (.[] | error)] catch ["KO", .]
{"a":["b"],"c":["d"]}
["KO",["b"]]
#
# Negative array indices
#
try (.foo[-1] = 0) catch .
null
"Out of bounds negative array index"
try (.foo[-2] = 0) catch .
null
"Out of bounds negative array index"
.[-1] = 5
[0,1,2]
[0,1,5]
.[-2] = 5
[0,1,2]
[0,5,2]
try (.[999999999] = 0) catch .
null
"Array index too large"
#
# Multiple outputs, iteration
#
.[]
[1,2,3]
1
2
3
1,1
[]
1
1
1,.
[]
1
[]
[.]
[2]
[[2]]
[[2]]
[3]
[[2]]
[{}]
[2]
[{}]
[.[]]
["a"]
["a"]
[(.,1),((.,.[]),(2,3))]
["a","b"]
[["a","b"],1,["a","b"],"a","b",2,3]
[([5,5][]),.,.[]]
[1,2,3]
[5,5,[1,2,3],1,2,3]
{x: (1,2)},{x:3} | .x
null
1
2
3
[.[-4,-3,-2,-1,0,1,2,3]]
[1,2,3]
[null,1,2,3,1,2,3,null]
[range(0;10)]
null
[0,1,2,3,4,5,6,7,8,9]
[range(0,1;3,4)]
null
[0,1,2, 0,1,2,3, 1,2, 1,2,3]
[range(0;10;3)]
null
[0,3,6,9]
[range(0;10;-1)]
null
[]
[range(0;-5;-1)]
null
[0,-1,-2,-3,-4]
[range(0,1;4,5;1,2)]
null
[0,1,2,3,0,2, 0,1,2,3,4,0,2,4, 1,2,3,1,3, 1,2,3,4,1,3]
[while(.<100; .*2)]
1
[1,2,4,8,16,32,64]
[(label $here | .[] | if .>1 then break $here else . end), "hi!"]
[0,1,2]
[0,1,"hi!"]
[(label $here | .[] | if .>1 then break $here else . end), "hi!"]
[0,2,1]
[0,"hi!"]
%%FAIL
. as $foo | break $foo
jq: error: $*label-foo is not defined at <top-level>, line 1, column 13:
. as $foo | break $foo
^^^^^^^^^^
[.[]|[.,1]|until(.[0] < 1; [.[0] - 1, .[1] * .[0]])|.[1]]
[1,2,3,4,5]
[1,2,6,24,120]
[label $out | foreach .[] as $item ([3, null]; if .[0] < 1 then break $out else [.[0] -1, $item] end; .[1])]
[11,22,33,44,55,66,77,88,99]
[11,22,33]
[foreach range(5) as $item (0; $item)]
null
[0,1,2,3,4]
[foreach .[] as [$i, $j] (0; . + $i - $j)]
[[2,1], [5,3], [6,4]]
[1,3,5]
[foreach .[] as {a:$a} (0; . + $a; -.)]
[{"a":1}, {"b":2}, {"a":3, "b":4}]
[-1, -1, -4]
[-foreach -.[] as $x (0; . + $x)]
[1,2,3]
[1,3,6]
[foreach .[] / .[] as $i (0; . + $i)]
[1,2]
[1,3,3.5,4.5]
[foreach .[] as $x (0; . + $x) as $x | $x]
[1,2,3]
[1,3,6]
[limit(3; .[])]
[11,22,33,44,55,66,77,88,99]
[11,22,33]
[limit(0; error)]
"badness"
[]
[limit(1; 1, error)]
"badness"
[1]
try limit(-1; error) catch .
null
"limit doesn't support negative count"
[skip(3; .[])]
[1,2,3,4,5,6,7,8,9]
[4,5,6,7,8,9]
[skip(0,2,3,4; .[])]
[1,2,3]
[1,2,3,3]
[skip(3; .[])]
[]
[]
try skip(-1; error) catch .
null
"skip doesn't support negative count"
nth(1; 0,1,error("foo"))
null
1
[first(range(.)), last(range(.))]
10
[0,9]
[first(range(.)), last(range(.))]
0
[]
[nth(0,5,9,10,15; range(.)), try nth(-1; range(.)) catch .]
10
[0,5,9,"nth doesn't support negative indices"]
# Check that first(g) does not extract more than one value from g
first(1,error("foo"))
null
1
#
# Check that various builtins evaluate all arguments where appropriate,
# doing cartesian products where appropriate.
#
# Check that limit does work for each value produced by n!
[limit(5,7; range(9))]
null
[0,1,2,3,4,0,1,2,3,4,5,6]
# Same check for nth
[nth(5,7; range(9;0;-1))]
null
[4,2]
# Same check for range/3
[range(0,1,2;4,3,2;2,3)]
null
[0,2,0,3,0,2,0,0,0,1,3,1,1,1,1,1,2,2,2,2]
# Same check for range/1
[range(3,5)]
null
[0,1,2,0,1,2,3,4]
# Same check for index/1, rindex/1, indices/1
[(index(",","|"), rindex(",","|")), indices(",","|")]
"a,b|c,d,e||f,g,h,|,|,i,j"
[1,3,22,19,[1,5,7,12,14,16,18,20,22],[3,9,10,17,19]]
# Same check for join/1
join(",","/")
["a","b","c","d"]
"a,b,c,d"
"a/b/c/d"
[.[]|join("a")]
[[],[""],["",""],["","",""]]
["","","a","aa"]
# Same check for flatten/1
flatten(3,2,1)
[0, [1], [[2]], [[[3]]]]
[0,1,2,3]
[0,1,2,[3]]
[0,1,[2],[[3]]]
#
# Slices
#
[.[3:2], .[-5:4], .[:-2], .[-2:], .[3:3][1:], .[10:]]
[0,1,2,3,4,5,6]
[[], [2,3], [0,1,2,3,4], [5,6], [], []]
[.[3:2], .[-5:4], .[:-2], .[-2:], .[3:3][1:], .[10:]]
"abcdefghi"
["","","abcdefg","hi","",""]
del(.[2:4],.[0],.[-2:])
[0,1,2,3,4,5,6,7]
[1,4,5]
.[2:4] = ([], ["a","b"], ["a","b","c"])
[0,1,2,3,4,5,6,7]
[0,1,4,5,6,7]
[0,1,"a","b",4,5,6,7]
[0,1,"a","b","c",4,5,6,7]
# Slices at large offsets (issue #1108)
#
# This is written this way because [range(<large number>)] is
# significantly slower under valgrind than .[<large number>] = value.
#
# We range down rather than up so that we have just one realloc.
reduce range(65540;65536;-1) as $i ([]; .[$i] = $i)|.[65536:]
null
[null,65537,65538,65539,65540]
#
# Variables
#
1 as $x | 2 as $y | [$x,$y,$x]
null
[1,2,1]
[1,2,3][] as $x | [[4,5,6,7][$x]]
null
[5]
[6]
[7]
42 as $x | . | . | . + 432 | $x + 1
34324
43
1 + 2 as $x | -$x
null
-3
"x" as $x | "a"+"y" as $y | $x+","+$y
null
"x,ay"
1 as $x | [$x,$x,$x as $x | $x]
null
[1,1,1]
[1, {c:3, d:4}] as [$a, {c:$b, b:$c}] | $a, $b, $c
null
1
3
null
. as {as: $kw, "str": $str, ("e"+"x"+"p"): $exp} | [$kw, $str, $exp]
{"as": 1, "str": 2, "exp": 3}
[1, 2, 3]
.[] as [$a, $b] | [$b, $a]
[[1], [1, 2, 3]]
[null, 1]
[2, 1]
. as $i | . as [$i] | $i
[0]
0
. as [$i] | . as $i | $i
[0]
[0]
%%FAIL
. as [] | null
jq: error: syntax error, unexpected ']', expecting BINDING or '[' or '{' at <top-level>, line 1, column 7:
. as [] | null
^
%%FAIL
. as {} | null
jq: error: syntax error, unexpected '}' at <top-level>, line 1, column 7:
. as {} | null
^
%%FAIL
. as $foo | [$foo, $bar]
jq: error: $bar is not defined at <top-level>, line 1, column 20:
. as $foo | [$foo, $bar]
^^^^
%%FAIL
. as {(true):$foo} | $foo
jq: error: Cannot use boolean (true) as object key at <top-level>, line 1, column 8:
. as {(true):$foo} | $foo
^^^^
# [.,(.[] | {x:.},.),.,.[]]
#
# Builtin functions
#
1+1
null
2
1+1
"wtasdf"
2.0
2-1
null
1
2-(-1)
null
3
1e+0+0.001e3
"I wonder what this will be?"
20e-1
.+4
15
19.0
.+null
{"a":42}
{"a":42}
null+.
null
null
.a+.b
{"a":42}
42
[1,2,3] + [.]
null
[1,2,3,null]
{"a":1} + {"b":2} + {"c":3}
"asdfasdf"
{"a":1, "b":2, "c":3}
"asdf" + "jkl;" + . + . + .
"some string"
"asdfjkl;some stringsome stringsome string"
"\u0000\u0020\u0000" + .
"\u0000\u0020\u0000"
"\u0000 \u0000\u0000 \u0000"
42 - .
11
31
[1,2,3,4,1] - [.,3]
1
[2,4]
[-1 as $x | 1,$x]
null
[1,-1]
[10 * 20, 20 / .]
4
[200, 5]
1 + 2 * 2 + 10 / 2
null
10
[16 / 4 / 2, 16 / 4 * 2, 16 - 4 - 2, 16 - 4 + 2]
null
[2, 8, 10, 14]
1e-19 + 1e-20 - 5e-21
null
1.05e-19
1 / 1e-17
null
1e+17
9E999999999, 9999999999E999999990, 1E-999999999, 0.000000001E-999999990
null
9E+999999999
9.999999999E+999999999
1E-999999999
1E-999999999
5E500000000 > 5E-5000000000, 10000E500000000 > 10000E-5000000000
null
true
true
# #2825
(1e999999999, 10e999999999) > (1e-1147483646, 0.1e-1147483646)
null
true
true
true
true
25 % 7
null
4
49732 % 472
null
172
[(infinite, -infinite) % (1, -1, infinite)]
null
[0,0,0,0,0,-1]
[nan % 1, 1 % nan | isnan]
null
[true,true]
1 + tonumber + ("10" | tonumber)
4
15
"123\u0000456" | try tonumber catch .
null
"string (\"123\\u0000456\") cannot be parsed as a number"
map(toboolean)
["false","true",false,true]
[false,true,false,true]
.[] | try toboolean catch .
[null,0,"tru","truee","fals","falsee",[],{}]
"null (null) cannot be parsed as a boolean"
"number (0) cannot be parsed as a boolean"
"string (\"tru\") cannot be parsed as a boolean"
"string (\"truee\") cannot be parsed as a boolean"
"string (\"fals\") cannot be parsed as a boolean"
"string (\"falsee\") cannot be parsed as a boolean"
"array ([]) cannot be parsed as a boolean"
"object ({}) cannot be parsed as a boolean"
"true\u0000x", "false\u0000" | try toboolean catch .
null
"string (\"true\\u0000x\") cannot be parsed as a boolean"
"string (\"false\\u0000\") cannot be parsed as a boolean"
[{"a":42},.object,10,.num,false,true,null,"b",[1,4]] | .[] as $x | [$x == .[]]
{"object": {"a":42}, "num":10.0}
[true, true, false, false, false, false, false, false, false]
[true, true, false, false, false, false, false, false, false]
[false, false, true, true, false, false, false, false, false]
[false, false, true, true, false, false, false, false, false]
[false, false, false, false, true, false, false, false, false]
[false, false, false, false, false, true, false, false, false]
[false, false, false, false, false, false, true, false, false]
[false, false, false, false, false, false, false, true, false]
[false, false, false, false, false, false, false, false, true ]
[.[] | length]
[[], {}, [1,2], {"a":42}, "asdf", "\u03bc"]
[0, 0, 2, 1, 4, 1]
utf8bytelength
"asdf\u03bc"
6
[.[] | try utf8bytelength catch .]
[[], {}, [1,2], 55, true, false]
["array ([]) only strings have UTF-8 byte length","object ({}) only strings have UTF-8 byte length","array ([1,2]) only strings have UTF-8 byte length","number (55) only strings have UTF-8 byte length","boolean (true) only strings have UTF-8 byte length","boolean (false) only strings have UTF-8 byte length"]
map(keys)
[{}, {"abcd":1,"abc":2,"abcde":3}, {"x":1, "z": 3, "y":2}]
[[], ["abc","abcd","abcde"], ["x","y","z"]]
[1,2,empty,3,empty,4]
null
[1,2,3,4]
map(add)
[[], [1,2,3], ["a","b","c"], [[3],[4,5],[6]], [{"a":1}, {"b":2}, {"a":3}]]
[null, 6, "abc", [3,4,5,6], {"a":3, "b": 2}]
map_values(.+1)
[0,1,2]
[1,2,3]
[add(null), add(range(range(10))), add(empty), add(10,range(10))]
null
[null,120,null,55]
# Real-world use case for add(empty)
.sum = add(.arr[])
{"arr":[]}
{"arr":[],"sum":null}
add({(.[]):1}) | keys
["a","a","b","a","d","b","d","a","d"]
["a","b","d"]
#
# User-defined functions
# Oh god.
#
def f: . + 1; def g: def g: . + 100; f | g | f; (f | g), g
3.0
106.0
105.0
def f: (1000,2000); f
123412345
1000
2000
def f(a;b;c;d;e;f): [a+1,b,c,d,e,f]; f(.[0];.[1];.[0];.[0];.[0];.[0])
[1,2]
[2,2,1,1,1,1]
def f: 1; def g: f, def f: 2; def g: 3; f, def f: g; f, g; def f: 4; [f, def f: g; def g: 5; f, g]+[f,g]
null
[4,1,2,3,3,5,4,1,2,3,3]
# Test precedence of 'def' vs '|'
def a: 0; . | a
null
0
# Many arguments
def f(a;b;c;d;e;f;g;h;i;j): [j,i,h,g,f,e,d,c,b,a]; f(.[0];.[1];.[2];.[3];.[4];.[5];.[6];.[7];.[8];.[9])
[0,1,2,3,4,5,6,7,8,9]
[9,8,7,6,5,4,3,2,1,0]
([1,2] + [4,5])
[1,2,3]
[1,2,4,5]
true
[1]
true
null,1,null
"hello"
null
1
null
[1,2,3]
[5,6]
[1,2,3]
[.[]|floor]
[-1.1,1.1,1.9]
[-2, 1, 1]
[.[]|sqrt]
[4,9]
[2,3]
(add / length) as $m | map((. - $m) as $d | $d * $d) | add / length | sqrt
[2,4,4,4,5,5,7,9]
2
# Should write a test that calls the -lm function from C (or bc(1)) to
# check that they match the corresponding jq functions. However,
# there's so little template code standing between that it suffices to
# test a handful of these. The results were checked by eye against
# bc(1).
atan * 4 * 1000000|floor / 1000000
1
3.141592
[(3.141592 / 2) * (range(0;20) / 20)|cos * 1000000|floor / 1000000]
null
[1,0.996917,0.987688,0.972369,0.951056,0.923879,0.891006,0.85264,0.809017,0.760406,0.707106,0.649448,0.587785,0.522498,0.45399,0.382683,0.309017,0.233445,0.156434,0.078459]
[(3.141592 / 2) * (range(0;20) / 20)|sin * 1000000|floor / 1000000]
null
[0,0.078459,0.156434,0.233445,0.309016,0.382683,0.45399,0.522498,0.587785,0.649447,0.707106,0.760405,0.809016,0.85264,0.891006,0.923879,0.951056,0.972369,0.987688,0.996917]
def f(x): x | x; f([.], . + [42])
[1,2,3]
[[[1,2,3]]]
[[1,2,3],42]
[[1,2,3,42]]
[1,2,3,42,42]
# test multiple function arities and redefinition
def f: .+1; def g: f; def f: .+100; def f(a):a+.+11; [(g|f(20)), f]
1
[33,101]
# test closures and lexical scoping
def id(x):x; 2000 as $x | def f(x):1 as $x | id([$x, x, x]); def g(x): 100 as $x | f($x,$x+x); g($x)
"more testing"
[1,100,2100.0,100,2100.0]
# test def f($a) syntax
def x(a;b): a as $a | b as $b | $a + $b; def y($a;$b): $a + $b; def check(a;b): [x(a;b)] == [y(a;b)]; check(.[];.[]*2)
[1,2,3]
true
# test backtracking through function calls and returns
# this test is *evil*
[[20,10][1,0] as $x | def f: (100,200) as $y | def g: [$x + $y, .]; . + $x | g; f[0] | [f][0][1] | f]
999999999
[[110.0, 130.0], [210.0, 130.0], [110.0, 230.0], [210.0, 230.0], [120.0, 160.0], [220.0, 160.0], [120.0, 260.0], [220.0, 260.0]]
# test recursion
def fac: if . == 1 then 1 else . * (. - 1 | fac) end; [.[] | fac]
[1,2,3,4]
[1,2,6,24]
# test stack overflow and reallocation
# this test is disabled for now, it takes a realllllly long time.
# def f: if length > 1000 then . else .+[1]|f end; f | length
# []
# 1001
reduce .[] as $x (0; . + $x)
[1,2,4]
7
reduce .[] as [$i, {j:$j}] (0; . + $i - $j)
[[2,{"j":1}], [5,{"j":3}], [6,{"j":4}]]
5
reduce [[1,2,10], [3,4,10]][] as [$i,$j] (0; . + $i * $j)
null
14
[-reduce -.[] as $x (0; . + $x)]
[1,2,3]
[6]
[reduce .[] / .[] as $i (0; . + $i)]
[1,2]
[4.5]
reduce .[] as $x (0; . + $x) as $x | $x
[1,2,3]
6
# This, while useless, should still compile.
reduce . as $n (.; .)
null
null
# Destructuring
. as {$a, b: [$c, {$d}]} | [$a, $c, $d]
{"a":1, "b":[2,{"d":3}]}
[1,2,3]
. as {$a, $b:[$c, $d]}| [$a, $b, $c, $d]
{"a":1, "b":[2,{"d":3}]}
[1,[2,{"d":3}],2,{"d":3}]
# Destructuring with alternation
.[] | . as {$a, b: [$c, {$d}]} ?// [$a, {$b}, $e] ?// $f | [$a, $b, $c, $d, $e, $f]
[{"a":1, "b":[2,{"d":3}]}, [4, {"b":5, "c":6}, 7, 8, 9], "foo"]
[1, null, 2, 3, null, null]
[4, 5, null, null, 7, null]
[null, null, null, null, null, "foo"]
# Destructuring DUP/POP issues
.[] | . as {a:$a} ?// {a:$a} ?// {a:$a} | $a
[[3],[4],[5],6]
# Runtime error: "jq: Cannot index array with string (\"c\")"
.[] as {a:$a} ?// {a:$a} ?// {a:$a} | $a
[[3],[4],[5],6]
# Runtime error: "jq: Cannot index array with string (\"c\")"
[[3],[4],[5],6][] | . as {a:$a} ?// {a:$a} ?// {a:$a} | $a
null
# Runtime error: "jq: Cannot index array with string (\"c\")"
[[3],[4],[5],6] | .[] as {a:$a} ?// {a:$a} ?// {a:$a} | $a
null
# Runtime error: "jq: Cannot index array with string (\"c\")"
.[] | . as {a:$a} ?// {a:$a} ?// $a | $a
[[3],[4],[5],6]
[3]
[4]
[5]
6
.[] as {a:$a} ?// {a:$a} ?// $a | $a
[[3],[4],[5],6]
[3]
[4]
[5]
6
[[3],[4],[5],6][] | . as {a:$a} ?// {a:$a} ?// $a | $a
null
[3]
[4]
[5]
6
[[3],[4],[5],6] | .[] as {a:$a} ?// {a:$a} ?// $a | $a
null
[3]
[4]
[5]
6
.[] | . as {a:$a} ?// $a ?// {a:$a} | $a
[[3],[4],[5],6]
[3]
[4]
[5]
6
.[] as {a:$a} ?// $a ?// {a:$a} | $a
[[3],[4],[5],6]
[3]
[4]
[5]
6
[[3],[4],[5],6][] | . as {a:$a} ?// $a ?// {a:$a} | $a
null
[3]
[4]
[5]
6
[[3],[4],[5],6] | .[] as {a:$a} ?// $a ?// {a:$a} | $a
null
[3]
[4]
[5]
6
.[] | . as $a ?// {a:$a} ?// {a:$a} | $a
[[3],[4],[5],6]
[3]
[4]
[5]
6
.[] as $a ?// {a:$a} ?// {a:$a} | $a
[[3],[4],[5],6]
[3]
[4]
[5]
6
[[3],[4],[5],6][] | . as $a ?// {a:$a} ?// {a:$a} | $a
null
[3]
[4]
[5]
6
[[3],[4],[5],6] | .[] as $a ?// {a:$a} ?// {a:$a} | $a
null
[3]
[4]
[5]
6
. as $dot|any($dot[];not)
[1,2,3,4,true,false,1,2,3,4,5]
true
. as $dot|any($dot[];not)
[1,2,3,4,true]
false
. as $dot|all($dot[];.)
[1,2,3,4,true,false,1,2,3,4,5]
false
. as $dot|all($dot[];.)
[1,2,3,4,true]
true
# Check short-circuiting
any(true, error; .)
"badness"
true
all(false, error; .)
"badness"
false
any(not)
[]
false
all(not)
[]
true
any(not)
[false]
true
all(not)
[false]
true
[any,all]
[]
[false,true]
[any,all]
[true]
[true,true]
[any,all]
[false]
[false,false]
[any,all]
[true,false]
[true,false]
[any,all]
[null,null,true]
[true,false]
#
# Paths
#
path(.foo[0,1])
null
["foo", 0]
["foo", 1]
path(.[] | select(.>3))
[1,5,3]
[1]
path(.)
42
[]
try path(.a | map(select(.b == 0))) catch .
{"a":[{"b":0}]}
"Invalid path expression with result [{\"b\":0}]"
try path(.a | map(select(.b == 0)) | .[0]) catch .
{"a":[{"b":0}]}
"Invalid path expression near attempt to access element 0 of [{\"b\":0}]"
try path(.a | map(select(.b == 0)) | .c) catch .
{"a":[{"b":0}]}
"Invalid path expression near attempt to access element \"c\" of [{\"b\":0}]"
try path(.a | map(select(.b == 0)) | .[]) catch .
{"a":[{"b":0}]}
"Invalid path expression near attempt to iterate through [{\"b\":0}]"
path(.a[path(.b)[0]])
{"a":{"b":0}}
["a","b"]
[paths]
[1,[[],{"a":2}]]
[[0],[1],[1,0],[1,1],[1,1,"a"]]
["foo",1] as $p | getpath($p), setpath($p; 20), delpaths([$p])
{"bar": 42, "foo": ["a", "b", "c", "d"]}
"b"
{"bar": 42, "foo": ["a", 20, "c", "d"]}
{"bar": 42, "foo": ["a", "c", "d"]}
map(getpath([2])), map(setpath([2]; 42)), map(delpaths([[2]]))
[[0], [0,1], [0,1,2]]
[null, null, 2]
[[0,null,42], [0,1,42], [0,1,42]]
[[0], [0,1], [0,1]]
map(delpaths([[0,"foo"]]))
[[{"foo":2, "x":1}], [{"bar":2}]]
[[{"x":1}], [{"bar":2}]]
["foo",1] as $p | getpath($p), setpath($p; 20), delpaths([$p])
{"bar":false}
null
{"bar":false, "foo": [null, 20]}
{"bar":false}
delpaths([[-200]])
[1,2,3]
[1,2,3]
try delpaths(0) catch .
{}
"Paths must be specified as an array"
del(.), del(empty), del((.foo,.bar,.baz) | .[2,3,0]), del(.foo[0], .bar[0], .foo, .baz.bar[0].x)
{"foo": [0,1,2,3,4], "bar": [0,1]}
null
{"foo": [0,1,2,3,4], "bar": [0,1]}
{"foo": [1,4], "bar": [1]}
{"bar": [1]}
del(.[1], .[-6], .[2], .[-3:9])
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 3, 5, 6, 9]
del(.[nan])
[1,2,3]
[1,2,3]
del(.[nan,nan])
[1,2,3]
[1,2,3]
# negative index
setpath([-1]; 1)
[0]
[1]
pick(.a.b.c)
null
{"a":{"b":{"c":null}}}
pick(first)
[1,2]
[1]
pick(first|first)
[[10,20],30]
[[10]]
# negative indices in path expressions (since last/1 is .[-1])
try pick(last) catch .
[1,2]
"Out of bounds negative array index"
#
# Assignment
#
.message = "goodbye"
{"message": "hello"}
{"message": "goodbye"}
.foo = .bar
{"bar":42}
{"foo":42, "bar":42}
.foo |= .+1
{"foo": 42}
{"foo": 43}
.[] += 2, .[] *= 2, .[] -= 2, .[] /= 2, .[] %=2
[1,3,5]
[3,5,7]
[2,6,10]
[-1,1,3]
[0.5, 1.5, 2.5]
[1,1,1]
[.[] % 7]
[-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7]
[0,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,0]
.foo += .foo
{"foo":2}
{"foo":4}
.[0].a |= {"old":., "new":(.+1)}
[{"a":1,"b":2}]
[{"a":{"old":1, "new":2},"b":2}]
def inc(x): x |= .+1; inc(.[].a)
[{"a":1,"b":2},{"a":2,"b":4},{"a":7,"b":8}]
[{"a":2,"b":2},{"a":3,"b":4},{"a":8,"b":8}]
# #1358, getpath/1 should work in path expressions
.[] | try (getpath(["a",0,"b"]) |= 5) catch .
[null,{"b":0},{"a":0},{"a":null},{"a":[0,1]},{"a":{"b":1}},{"a":[{}]},{"a":[{"c":3}]}]
{"a":[{"b":5}]}
{"b":0,"a":[{"b":5}]}
"Cannot index number with number (0)"
{"a":[{"b":5}]}
"Cannot index number with string (\"b\")"
"Cannot index object with number (0)"
{"a":[{"b":5}]}
{"a":[{"c":3,"b":5}]}
# #2051, deletion using assigning empty against arrays
(.[] | select(. >= 2)) |= empty
[1,5,3,0,7]
[1,0]
.[] |= select(. % 2 == 0)
[0,1,2,3,4,5]
[0,2,4]
.foo[1,4,2,3] |= empty
{"foo":[0,1,2,3,4,5]}
{"foo":[0,5]}
.[2][3] = 1
[4]
[4, null, [null, null, null, 1]]
.foo[2].bar = 1
{"foo":[11], "bar":42}
{"foo":[11,null,{"bar":1}], "bar":42}
try ((map(select(.a == 1))[].b) = 10) catch .
[{"a":0},{"a":1}]
"Invalid path expression near attempt to iterate through [{\"a\":1}]"
try ((map(select(.a == 1))[].a) |= .+1) catch .
[{"a":0},{"a":1}]
"Invalid path expression near attempt to iterate through [{\"a\":1}]"
def x: .[1,2]; x=10
[0,1,2]
[0,10,10]
try (def x: reverse; x=10) catch .
[0,1,2]
"Invalid path expression with result [2,1,0]"
.[] = 1
[1,null,Infinity,-Infinity,NaN,-NaN]
[1,1,1,1,1,1]
#
# Conditionals
#
[.[] | if .foo then "yep" else "nope" end]
[{"foo":0},{"foo":1},{"foo":[]},{"foo":true},{"foo":false},{"foo":null},{"foo":"foo"},{}]
["yep","yep","yep","yep","nope","nope","yep","nope"]
[.[] | if .baz then "strange" elif .foo then "yep" else "nope" end]
[{"foo":0},{"foo":1},{"foo":[]},{"foo":true},{"foo":false},{"foo":null},{"foo":"foo"},{}]
["yep","yep","yep","yep","nope","nope","yep","nope"]
[if 1,null,2 then 3 else 4 end]
null
[3,4,3]
[if empty then 3 else 4 end]
null
[]
[if 1 then 3,4 else 5 end]
null
[3,4]
[if null then 3 else 5,6 end]
null
[5,6]
[if true then 3 end]
7
[3]
[if false then 3 end]
7
[7]
[if false then 3 else . end]
7
[7]
[if false then 3 elif false then 4 end]
7
[7]
[if false then 3 elif false then 4 else . end]
7
[7]
[-if true then 1 else 2 end]
null
[-1]
{x: if true then 1 else 2 end}
null
{"x":1}
if true then [.] else . end []
null
null
[.[] | [.foo[] // .bar]]
[{"foo":[1,2], "bar": 42}, {"foo":[1], "bar": null}, {"foo":[null,false,3], "bar": 18}, {"foo":[], "bar":42}, {"foo": [null,false,null], "bar": 41}]
[[1,2], [1], [3], [42], [41]]
.[] //= .[0]
["hello",true,false,[false],null]
["hello",true,"hello",[false],"hello"]
.[] | [.[0] and .[1], .[0] or .[1]]
[[true,[]], [false,1], [42,null], [null,false]]
[true,true]
[false,true]
[false,true]
[false,false]
[.[] | not]
[1,0,false,null,true,"hello"]
[false,false,true,true,false,false]
# Check numeric comparison binops
[10 > 0, 10 > 10, 10 > 20, 10 < 0, 10 < 10, 10 < 20]
{}
[true,false,false,false,false,true]
[10 >= 0, 10 >= 10, 10 >= 20, 10 <= 0, 10 <= 10, 10 <= 20]
{}
[true,true,false,false,true,true]
# And some in/equality tests
[ 10 == 10, 10 != 10, 10 != 11, 10 == 11]
{}
[true,false,true,false]
["hello" == "hello", "hello" != "hello", "hello" == "world", "hello" != "world" ]
{}
[true,false,false,true]
[[1,2,3] == [1,2,3], [1,2,3] != [1,2,3], [1,2,3] == [4,5,6], [1,2,3] != [4,5,6]]
{}
[true,false,false,true]
[{"foo":42} == {"foo":42},{"foo":42} != {"foo":42}, {"foo":42} != {"bar":42}, {"foo":42} == {"bar":42}]
{}
[true,false,true,false]
# ugly complicated thing
[{"foo":[1,2,{"bar":18},"world"]} == {"foo":[1,2,{"bar":18},"world"]},{"foo":[1,2,{"bar":18},"world"]} == {"foo":[1,2,{"bar":19},"world"]}]
{}
[true,false]
# containment operator
[("foo" | contains("foo")), ("foobar" | contains("foo")), ("foo" | contains("foobar"))]
{}
[true, true, false]
# containment operator (embedded NULs!)
[contains(""), contains("\u0000")]
"\u0000"
[true, true]
[contains(""), contains("a"), contains("ab"), contains("c"), contains("d")]
"ab\u0000cd"
[true, true, true, true, true]
[contains("cd"), contains("b\u0000"), contains("ab\u0000")]
"ab\u0000cd"
[true, true, true]
[contains("b\u0000c"), contains("b\u0000cd"), contains("b\u0000cd")]
"ab\u0000cd"
[true, true, true]
[contains("@"), contains("\u0000@"), contains("\u0000what")]
"ab\u0000cd"
[false, false, false]
# Try/catch and general `?` operator
[.[]|try if . == 0 then error("foo") elif . == 1 then .a elif . == 2 then empty else . end catch .]
[0,1,2,3]
["foo","Cannot index number with string (\"a\")",3]
[.[]|(.a, .a)?]
[null,true,{"a":1}]
[null,null,1,1]
[[.[]|[.a,.a]]?]
[null,true,{"a":1}]
[]
[if error then 1 else 2 end?]
"foo"
[]
try error(0) // 1
null
1
1, try error(2), 3
null
1
3
1 + try 2 catch 3 + 4
null
7
[-try .]
1
[-1]
try -.? catch .
"foo"
"string (\"foo\") cannot be negated"
{x: try 1, y: try error catch 2, z: if true then 3 end}
null
{"x":1,"y":2,"z":3}
{x: 1 + 2, y: false or true, z: null // 3}
null
{"x":3,"y":true,"z":3}
.[] | try error catch .
[1,null,2]
1
null
2
try error("\($__loc__)") catch .
null
"{\"file\":\"<top-level>\",\"line\":1}"
# string operations
[.[]|startswith("foo")]
["fo", "foo", "barfoo", "foobar", "barfoob"]
[false, true, false, true, false]
[.[]|endswith("foo")]
["fo", "foo", "barfoo", "foobar", "barfoob"]
[false, true, true, false, false]
[.[] | split(", ")]
["a,b, c, d, e,f",", a,b, c, d, e,f, "]
[["a,b","c","d","e,f"],["","a,b","c","d","e,f",""]]
split("")
"abc"
["a","b","c"]
[.[]|ltrimstr("foo")]
["fo", "foo", "barfoo", "foobar", "afoo"]
["fo","","barfoo","bar","afoo"]
[.[]|rtrimstr("foo")]
["fo", "foo", "barfoo", "foobar", "foob"]
["fo","","bar","foobar","foob"]
[.[]|trimstr("foo")]
["fo", "foo", "barfoo", "foobarfoo", "foob"]
["fo","","bar","bar","b"]
[.[]|ltrimstr("")]
["a", "xx", ""]
["a", "xx", ""]
[.[]|rtrimstr("")]
["a", "xx", ""]
["a", "xx", ""]
[.[]|trimstr("")]
["a", "xx", ""]
["a", "xx", ""]
[(index(","), rindex(",")), indices(",")]
"a,bc,def,ghij,klmno"
[1,13,[1,4,8,13]]
[ index("aba"), rindex("aba"), indices("aba") ]
"xababababax"
[1,7,[1,3,5,7]]
# _strindices is used by indices/1 but is callable
try _strindices("abc") catch .
123
"number (123) cannot be searched, as it is not a string"
try _strindices(123) catch .
"abc"
"number (123) is not a string"
# trim
# \u000b is vertical tab (\v not supported by json)
map(trim), map(ltrim), map(rtrim)
[" \n\t\r\f\u000b", ""," ", "a", " a ", "abc", " abc ", " abc", "abc "]
["", "", "", "a", "a", "abc", "abc", "abc", "abc"]
["", "", "", "a", "a ", "abc", "abc ", "abc", "abc "]
["", "", "", "a", " a", "abc", " abc", " abc", "abc"]
trim, ltrim, rtrim
"\u0009\u000A\u000B\u000C\u000D\u0020\u0085\u00A0\u1680\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200A\u2028\u2029\u202F\u205F\u3000abc\u0009\u000A\u000B\u000C\u000D\u0020\u0085\u00A0\u1680\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200A\u2028\u2029\u202F\u205F\u3000"
"abc"
"abc\u0009\u000A\u000B\u000C\u000D\u0020\u0085\u00A0\u1680\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200A\u2028\u2029\u202F\u205F\u3000"
"\u0009\u000A\u000B\u000C\u000D\u0020\u0085\u00A0\u1680\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200A\u2028\u2029\u202F\u205F\u3000abc"
try trim catch ., try ltrim catch ., try rtrim catch .
123
"trim input must be a string"
"trim input must be a string"
"trim input must be a string"
indices(1)
[0,1,1,2,3,4,1,5]
[1,2,6]
indices([1,2])
[0,1,2,3,1,4,2,5,1,2,6,7]
[1,8]
indices([1,2])
[1]
[]
indices(", ")
"a,b, cd,e, fgh, ijkl"
[3,9,14]
index("!")
"здравствуй мир!"
14
.[:rindex("x")]
"正xyz"
"正"
indices("o")
"🇬🇧oo"
[2,3]
indices("o")
"ƒoo"
[1,2]
[.[]|split(",")]
["a, bc, def, ghij, jklmn, a,b, c,d, e,f", "a,b,c,d, e,f,g,h"]
[["a"," bc"," def"," ghij"," jklmn"," a","b"," c","d"," e","f"],["a","b","c","d"," e","f","g","h"]]
[.[]|split(", ")]
["a, bc, def, ghij, jklmn, a,b, c,d, e,f", "a,b,c,d, e,f,g,h"]
[["a","bc","def","ghij","jklmn","a,b","c,d","e,f"],["a,b,c,d","e,f,g,h"]]
[.[] * 3]
["a", "ab", "abc"]
["aaa", "ababab", "abcabcabc"]
[.[] * "abc"]
[-1.0, -0.5, 0.0, 0.5, 1.0, 1.5, 3.7, 10.0]
[null,null,"","","abc","abc","abcabcabc","abcabcabcabcabcabcabcabcabcabc"]
[. * (nan,-nan)]
"abc"
[null,null]
. * 100000 | [.[:10],.[-10:]]
"abc"
["abcabcabca","cabcabcabc"]
. * 1000000000
""
""
try (. * 1000000000) catch .
"abc"
"Repeat string result too long"
[.[] / ","]
["a, bc, def, ghij, jklmn, a,b, c,d, e,f", "a,b,c,d, e,f,g,h"]
[["a"," bc"," def"," ghij"," jklmn"," a","b"," c","d"," e","f"],["a","b","c","d"," e","f","g","h"]]
[.[] / ", "]
["a, bc, def, ghij, jklmn, a,b, c,d, e,f", "a,b,c,d, e,f,g,h"]
[["a","bc","def","ghij","jklmn","a,b","c,d","e,f"],["a,b,c,d","e,f,g,h"]]
map(.[1] as $needle | .[0] | contains($needle))
[[[],[]], [[1,2,3], [1,2]], [[1,2,3], [3,1]], [[1,2,3], [4]], [[1,2,3], [1,4]]]
[true, true, true, false, false]
map(.[1] as $needle | .[0] | contains($needle))
[[["foobar", "foobaz"], ["baz", "bar"]], [["foobar", "foobaz"], ["foo"]], [["foobar", "foobaz"], ["blap"]]]
[true, true, false]
[({foo: 12, bar:13} | contains({foo: 12})), ({foo: 12} | contains({})), ({foo: 12, bar:13} | contains({baz:14}))]
{}
[true, true, false]
{foo: {baz: 12, blap: {bar: 13}}, bar: 14} | contains({bar: 14, foo: {blap: {}}})
{}
true
{foo: {baz: 12, blap: {bar: 13}}, bar: 14} | contains({bar: 14, foo: {blap: {bar: 14}}})
{}
false
sort
[42,[2,5,3,11],10,{"a":42,"b":2},{"a":42},true,2,[2,6],"hello",null,[2,5,6],{"a":[],"b":1},"abc","ab",[3,10],{},false,"abcd",null]
[null,null,false,true,2,10,42,"ab","abc","abcd","hello",[2,5,3,11],[2,5,6],[2,6],[3,10],{},{"a":42},{"a":42,"b":2},{"a":[],"b":1}]
(sort_by(.b) | sort_by(.a)), sort_by(.a, .b), sort_by(.b, .c), group_by(.b), group_by(.a + .b - .c == 2)
[{"a": 1, "b": 4, "c": 14}, {"a": 4, "b": 1, "c": 3}, {"a": 1, "b": 4, "c": 3}, {"a": 0, "b": 2, "c": 43}]
[{"a": 0, "b": 2, "c": 43}, {"a": 1, "b": 4, "c": 14}, {"a": 1, "b": 4, "c": 3}, {"a": 4, "b": 1, "c": 3}]
[{"a": 0, "b": 2, "c": 43}, {"a": 1, "b": 4, "c": 14}, {"a": 1, "b": 4, "c": 3}, {"a": 4, "b": 1, "c": 3}]
[{"a": 4, "b": 1, "c": 3}, {"a": 0, "b": 2, "c": 43}, {"a": 1, "b": 4, "c": 3}, {"a": 1, "b": 4, "c": 14}]
[[{"a": 4, "b": 1, "c": 3}], [{"a": 0, "b": 2, "c": 43}], [{"a": 1, "b": 4, "c": 14}, {"a": 1, "b": 4, "c": 3}]]
[[{"a": 1, "b": 4, "c": 14}, {"a": 0, "b": 2, "c": 43}], [{"a": 4, "b": 1, "c": 3}, {"a": 1, "b": 4, "c": 3}]]
unique
[1,2,5,3,5,3,1,3]
[1,2,3,5]
unique
[]
[]
[min, max, min_by(.[1]), max_by(.[1]), min_by(.[2]), max_by(.[2])]
[[4,2,"a"],[3,1,"a"],[2,4,"a"],[1,3,"a"]]
[[1,3,"a"],[4,2,"a"],[3,1,"a"],[2,4,"a"],[4,2,"a"],[1,3,"a"]]
[min,max,min_by(.),max_by(.)]
[]
[null,null,null,null]
.foo[.baz]
{"foo":{"bar":4},"baz":"bar"}
4
.[] | .error = "no, it's OK"
[{"error":true}]
{"error": "no, it's OK"}
[{a:1}] | .[] | .a=999
null
{"a": 999}
to_entries
{"a": 1, "b": 2}
[{"key":"a", "value":1}, {"key":"b", "value":2}]
from_entries
[{"key":"a", "value":1}, {"Key":"b", "Value":2}, {"name":"c", "value":3}, {"Name":"d", "Value":4}]
{"a": 1, "b": 2, "c": 3, "d": 4}
with_entries(.key |= "KEY_" + .)
{"a": 1, "b": 2}
{"KEY_a": 1, "KEY_b": 2}
map(has("foo"))
[{"foo": 42}, {}]
[true, false]
map(has(2))
[[0,1], ["a","b","c"]]
[false, true]
has(nan)
[0,1,2]
false
keys
[42,3,35]
[0,1,2]
[][.]
1000000000000000000
null
map([1,2][0:.])
[-1, 1, 2, 3, 1000000000000000000]
[[1], [1], [1,2], [1,2], [1,2]]
# Test recursive object merge
{"k": {"a": 1, "b": 2}} * .
{"k": {"a": 0,"c": 3}}
{"k": {"a": 0, "b": 2, "c": 3}}
{"k": {"a": 1, "b": 2}, "hello": {"x": 1}} * .
{"k": {"a": 0,"c": 3}, "hello": 1}
{"k": {"a": 0, "b": 2, "c": 3}, "hello": 1}
{"k": {"a": 1, "b": 2}, "hello": 1} * .
{"k": {"a": 0,"c": 3}, "hello": {"x": 1}}
{"k": {"a": 0, "b": 2, "c": 3}, "hello": {"x": 1}}
{"a": {"b": 1}, "c": {"d": 2}, "e": 5} * .
{"a": {"b": 2}, "c": {"d": 3, "f": 9}}
{"a": {"b": 2}, "c": {"d": 3, "f": 9}, "e": 5}
[.[]|arrays]
[1,2,"foo",[],[3,[]],{},true,false,null]
[[],[3,[]]]
[.[]|objects]
[1,2,"foo",[],[3,[]],{},true,false,null]
[{}]
[.[]|iterables]
[1,2,"foo",[],[3,[]],{},true,false,null]
[[],[3,[]],{}]
[.[]|scalars]
[1,2,"foo",[],[3,[]],{},true,false,null]
[1,2,"foo",true,false,null]
[.[]|values]
[1,2,"foo",[],[3,[]],{},true,false,null]
[1,2,"foo",[],[3,[]],{},true,false]
[.[]|booleans]
[1,2,"foo",[],[3,[]],{},true,false,null]
[true,false]
[.[]|nulls]
[1,2,"foo",[],[3,[]],{},true,false,null]
[null]
flatten
[0, [1], [[2]], [[[3]]]]
[0, 1, 2, 3]
flatten(0)
[0, [1], [[2]], [[[3]]]]
[0, [1], [[2]], [[[3]]]]
flatten(2)
[0, [1], [[2]], [[[3]]]]
[0, 1, 2, [3]]
flatten(2)
[0, [1, [2]], [1, [[3], 2]]]
[0, 1, 2, 1, [3], 2]
try flatten(-1) catch .
[0, [1], [[2]], [[[3]]]]
"flatten depth must not be negative"
transpose
[[1], [2,3]]
[[1,2],[null,3]]
transpose
[]
[]
ascii_upcase
"useful but not for é"
"USEFUL BUT NOT FOR é"
bsearch(0,1,2,3,4)
[1,2,3]
-1
0
1
2
-4
bsearch({x:1})
[{ "x": 0 },{ "x": 1 },{ "x": 2 }]
1
try ["OK", bsearch(0)] catch ["KO",.]
"aa"
["KO","string (\"aa\") cannot be searched from"]
strftime("%Y-%m-%dT%H:%M:%SZ")
[2015,2,5,23,51,47,4,63]
"2015-03-05T23:51:47Z"
strftime("%A, %B %d, %Y")
1435677542.822351
"Tuesday, June 30, 2015"
strftime("%Y-%m-%dT%H:%M:%SZ")
[2024,2,15]
"2024-03-15T00:00:00Z"
mktime
[2024,8,21]
1726876800
gmtime
1425599507
[2015,2,5,23,51,47,4,63]
gmtime[5]
1425599507.25
47.25
# test invalid tm input
try strftime("%Y-%m-%dT%H:%M:%SZ") catch .
["a",1,2,3,4,5,6,7]
"strftime/1 requires parsed datetime inputs"
try strflocaltime("%Y-%m-%dT%H:%M:%SZ") catch .
["a",1,2,3,4,5,6,7]
"strflocaltime/1 requires parsed datetime inputs"
try mktime catch .
["a",1,2,3,4,5,6,7]
"mktime requires parsed datetime inputs"
# oss-fuzz #67403: non-string argument with number input fails assert
try ["OK", strftime([])] catch ["KO", .]
0
["KO","strftime/1 requires a string format"]
try ["OK", strflocaltime({})] catch ["KO", .]
0
["KO","strflocaltime/1 requires a string format"]
[strptime("%Y-%m-%dT%H:%M:%SZ")|(.,mktime)]
"2015-03-05T23:51:47Z"
[[2015,2,5,23,51,47,4,63],1425599507]
# Check day-of-week and day of year computations
# (should trip an assert if this fails)
last(range(365 * 67)|("1970-03-01T01:02:03Z"|strptime("%Y-%m-%dT%H:%M:%SZ")|mktime) + (86400 * .)|strftime("%Y-%m-%dT%H:%M:%SZ")|strptime("%Y-%m-%dT%H:%M:%SZ"))
null
[2037,1,11,1,2,3,3,41]
# module system
import "a" as foo; import "b" as bar; def fooa: foo::a; [fooa, bar::a, bar::b, foo::a]
null
["a","b","c","a"]
import "c" as foo; [foo::a, foo::c]
null
[0,"acmehbah"]
include "c"; [a, c]
null
[0,"acmehbah"]
import "data" as $e; import "data" as $d; [$d[].this,$e[].that,$d::d[].this,$e::e[].that]|join(";")
null
"is a test;is too;is a test;is too"
# Regression test for #2000
import "data" as $a; import "data" as $b; def f: {$a, $b}; f
null
{"a":[{"this":"is a test","that":"is too"}],"b":[{"this":"is a test","that":"is too"}]}
include "shadow1"; e
null
2
include "shadow1"; include "shadow2"; e
null
3
import "shadow1" as f; import "shadow2" as f; import "shadow1" as e; [e::e, f::e]
null
[2,3]
%%FAIL
module (.+1); 0
jq: error: Module metadata must be constant at <top-level>, line 1, column 8:
module (.+1); 0
^^^^^
%%FAIL
module []; 0
jq: error: Module metadata must be an object at <top-level>, line 1, column 8:
module []; 0
^^
%%FAIL
include "a" (.+1); 0
jq: error: Module metadata must be constant at <top-level>, line 1, column 13:
include "a" (.+1); 0
^^^^^
%%FAIL
include "a" []; 0
jq: error: Module metadata must be an object at <top-level>, line 1, column 13:
include "a" []; 0
^^
%%FAIL
include "\ "; 0
jq: error: Invalid escape at line 1, column 4 (while parsing '"\ "') at <top-level>, line 1, column 10:
include "\ "; 0
^^
%%FAIL
include "\(a)"; 0
jq: error: Import path must be constant at <top-level>, line 1, column 9:
include "\(a)"; 0
^^^^^^
modulemeta
"c"
{"whatever":null,"deps":[{"as":"foo","is_data":false,"relpath":"a"},{"search":"./","as":"d","is_data":false,"relpath":"d"},{"search":"./","as":"d2","is_data":false,"relpath":"d"},{"search":"./../lib/jq","as":"e","is_data":false,"relpath":"e"},{"search":"./../lib/jq","as":"f","is_data":false,"relpath":"f"},{"as":"d","is_data":true,"relpath":"data"}],"defs":["a/0","c/0"]}
modulemeta | .deps | length
"c"
6
modulemeta | .defs | length
"c"
2
%%FAIL IGNORE MSG
import "syntaxerror" as e; .
jq: error: syntax error, unexpected ';', expecting end of file at tests/modules/syntaxerror/syntaxerror.jq, line 1, column 4:
wat;
^
%%FAIL
%::wat
jq: error: syntax error, unexpected '%', expecting end of file at <top-level>, line 1, column 1:
%::wat
^
import "test_bind_order" as check; check::check
null
true
try -. catch .
"very-long-long-long-long-string"
"string (\"very-long-long-long-long...\") cannot be negated"
try (.-.) catch .
"very-long-long-long-long-string"
"string (\"very-long-long-long-long...\") and string (\"very-long-long-long-long...\") cannot be subtracted"
"x" * range(0; 12; 2) + "☆" * 8 | try -. catch .
null
"string (\"☆☆☆☆☆☆☆☆\") cannot be negated"
"string (\"xx☆☆☆☆☆☆☆☆\") cannot be negated"
"string (\"xxxx☆☆☆☆☆☆...\") cannot be negated"
"string (\"xxxxxx☆☆☆☆☆☆...\") cannot be negated"
"string (\"xxxxxxxx☆☆☆☆☆...\") cannot be negated"
"string (\"xxxxxxxxxx☆☆☆☆...\") cannot be negated"
try (. + "x") catch . == if have_decnum then "number (12345678901234567890123456...) and string (\"x\") cannot be added" else "number (12345678901234568000000000...) and string (\"x\") cannot be added" end
123456789012345678901234567890
true
join(",")
["1",2,true,false,3.4]
"1,2,true,false,3.4"
.[] | join(",")
[[], [null], [null,null], [null,null,null]]
""
""
","
",,"
.[] | join(",")
[["a",null], [null,"a"]]
"a,"
",a"
try join(",") catch .
["1","2",{"a":{"b":{"c":33}}}]
"string (\"1,2,\") and object ({\"a\":{\"b\":{\"c\":33}}}) cannot be added"
try join(",") catch .
["1","2",[3,4,5]]
"string (\"1,2,\") and array ([3,4,5]) cannot be added"
{if:0,and:1,or:2,then:3,else:4,elif:5,end:6,as:7,def:8,reduce:9,foreach:10,try:11,catch:12,label:13,import:14,include:15,module:16}
null
{"if":0,"and":1,"or":2,"then":3,"else":4,"elif":5,"end":6,"as":7,"def":8,"reduce":9,"foreach":10,"try":11,"catch":12,"label":13,"import":14,"include":15,"module":16}
try (1/.) catch .
0
"number (1) and number (0) cannot be divided because the divisor is zero"
try (1/0) catch .
0
"number (1) and number (0) cannot be divided because the divisor is zero"
try (0/0) catch .
0
"number (0) and number (0) cannot be divided because the divisor is zero"
try (1%.) catch .
0
"number (1) and number (0) cannot be divided (remainder) because the divisor is zero"
try (1%0) catch .
0
"number (1) and number (0) cannot be divided (remainder) because the divisor is zero"
# Basic numbers tests: integers, powers of two
[range(-52;52;1)] as $powers | [$powers[]|pow(2;.)|log2|round] == $powers
null
true
[range(-99/2;99/2;1)] as $orig | [$orig[]|pow(2;.)|log2] as $back | ($orig|keys)[]|. as $k | (($orig|.[$k])-($back|.[$k]))|if . < 0 then . * -1 else . end|select(.>.00005)
null
%%FAIL
{
jq: error: syntax error, unexpected end of file at <top-level>, line 1, column 1:
{
^
%%FAIL
}
jq: error: syntax error, unexpected INVALID_CHARACTER, expecting end of file at <top-level>, line 1, column 1:
}
^
(.[{}] = 0)?
null
INDEX(range(5)|[., "foo\(.)"]; .[0])
null
{"0":[0,"foo0"],"1":[1,"foo1"],"2":[2,"foo2"],"3":[3,"foo3"],"4":[4,"foo4"]}
JOIN({"0":[0,"abc"],"1":[1,"bcd"],"2":[2,"def"],"3":[3,"efg"],"4":[4,"fgh"]}; .[0]|tostring)
[[5,"foo"],[3,"bar"],[1,"foobar"]]
[[[5,"foo"],null],[[3,"bar"],[3,"efg"]],[[1,"foobar"],[1,"bcd"]]]
range(5;10)|IN(range(10))
null
true
true
true
true
true
range(5;13)|IN(range(0;10;3))
null
false
true
false
false
true
false
false
false
range(10;12)|IN(range(10))
null
false
false
IN(range(10;20); range(10))
null
false
IN(range(5;20); range(10))
null
true
# Regression test for #1347
(.a as $x | .b) = "b"
{"a":null,"b":null}
{"a":null,"b":"b"}
# Regression test for #1368
(.. | select(type == "object" and has("b") and (.b | type) == "array")|.b) |= .[0]
{"a": {"b": [1, {"b": 3}]}}
{"a": {"b": 1}}
isempty(empty)
null
true
isempty(range(3))
null
false
isempty(1,error("foo"))
null
false
# Regression test for #1815
index("")
""
null
# check that dead code removal occurs after builtin it generation
builtins|length > 10
null
true
"-1"|IN(builtins[] / "/"|.[1])
null
false
all(builtins[] / "/"; .[1]|tonumber >= 0)
null
true
builtins|any(.[:1] == "_")
null
false
## Test ability to use keywords (uncomment after eval is pushed)
#(.[] as $kw | "\"{\($kw)} as $\($kw) | $\($kw) | {$\($kw)} | {\($kw):.\($kw)}\""|eval|empty),null
#["as","def","module","import","include","if","then","else","elif","end","reduce","foreach","and","or","try","catch","label","break","__loc__"]
#null
#
#(.[] as $kw | "\"def f($\($kw)): $\($kw); f(.)\""|eval|empty),null
#["as","def","module","import","include","if","then","else","elif","end","reduce","foreach","and","or","try","catch","label","break","__loc__"]
#null
#
# Tests to cover the new toliteral number functionality
# For an example see #1652 and other linked issues
#
# We are backward and sanity compatible
map(. == 1)
[1, 1.0, 1.000, 100e-2, 1e+0, 0.0001e4]
[true, true, true, true, true, true]
# When no arithmetic is involved jq should preserve the literal value
.[0] | tostring | . == if have_decnum then "13911860366432393" else "13911860366432392" end
[13911860366432393]
true
.x | tojson | . == if have_decnum then "13911860366432393" else "13911860366432392" end
{"x":13911860366432393}
true
(13911860366432393 == 13911860366432392) | . == if have_decnum then false else true end
null
true
# Applying arithmetic to the value will truncate the result to double
. - 10
13911860366432393
13911860366432382
.[0] - 10
[13911860366432393]
13911860366432382
.x - 10
{"x":13911860366432393}
13911860366432382
# Unary negation preserves numerical precision
-. | tojson == if have_decnum then "-13911860366432393" else "-13911860366432392" end
13911860366432393
true
-. | tojson == if have_decnum then "0.12345678901234567890123456789" else "0.12345678901234568" end
-0.12345678901234567890123456789
true
[1E+1000,-1E+1000 | tojson] == if have_decnum then ["1E+1000","-1E+1000"] else ["1.7976931348623157e+308","-1.7976931348623157e+308"] end
null
true
. |= try . catch .
1
1
# decnum to double conversion
.[] as $n | $n+0 | [., tostring, . == $n]
[-9007199254740993, -9007199254740992, 9007199254740992, 9007199254740993, 13911860366432393]
[-9007199254740992,"-9007199254740992",true]
[-9007199254740992,"-9007199254740992",true]
[9007199254740992,"9007199254740992",true]
[9007199254740992,"9007199254740992",true]
[13911860366432392,"13911860366432392",true]
# abs, fabs, length
abs
"abc"
"abc"
map(abs)
[-0, 0, -10, -1.1]
[0,0,10,1.1]
map(fabs)
[-0, 0, -10, -1.1]
[0,0,10,1.1]
map(abs == length) | unique
[-10, -1.1, -1e-1, 1000000000000000002]
[true]
# The following is NOT prescriptive:
map(abs)
[0.1,1000000000000000002]
[1e-1, 1000000000000000002]
[1E+1000,-1E+1000 | abs | tojson] | unique == if have_decnum then ["1E+1000"] else ["1.7976931348623157e+308"] end
null
true
[1E+1000,-1E+1000 | length | tojson] | unique == if have_decnum then ["1E+1000"] else ["1.7976931348623157e+308"] end
null
true
# Using a keyword as variable/label name
123 as $label | $label
null
123
[ label $if | range(10) | ., (select(. == 5) | break $if) ]
null
[0,1,2,3,4,5]
reduce .[] as $then (4 as $else | $else; . as $elif | . + $then * $elif)
[1,2,3]
96
1 as $foreach | 2 as $and | 3 as $or | { $foreach, $and, $or, a }
{"a":4,"b":5}
{"foreach":1,"and":2,"or":3,"a":4}
[ foreach .[] as $try (1 as $catch | $catch - 1; . + $try; .) ]
[10,9,8,7]
[10,19,27,34]
# Object construction
{ a, $__loc__, c }
{"a":[1,2,3],"b":"foo","c":{"hi":"hey"}}
{"a":[1,2,3],"__loc__":{"file":"<top-level>","line":1},"c":{"hi":"hey"}}
1 as $x | "2" as $y | "3" as $z | { $x, as, $y: 4, ($z): 5, if: 6, foo: 7 }
{"as":8}
{"x":1,"as":8,"2":4,"3":5,"if":6,"foo":7}
# nan is parsed as a valid NaN value from JSON
fromjson | isnan
"nan"
true
tojson | fromjson
{"a":nan}
{"a":null}
# NaN with payload is not parsed
.[] | try (fromjson | isnan) catch .
["NaN","-NaN","NaN1","NaN10","NaN100","NaN1000","NaN10000","NaN100000"]
true
true
"Invalid numeric literal at EOF at line 1, column 4 (while parsing 'NaN1')"
"Invalid numeric literal at EOF at line 1, column 5 (while parsing 'NaN10')"
"Invalid numeric literal at EOF at line 1, column 6 (while parsing 'NaN100')"
"Invalid numeric literal at EOF at line 1, column 7 (while parsing 'NaN1000')"
"Invalid numeric literal at EOF at line 1, column 8 (while parsing 'NaN10000')"
"Invalid numeric literal at EOF at line 1, column 9 (while parsing 'NaN100000')"
# calling input/0, or debug/0 in a test doesn't crash jq
try input catch .
null
"break"
debug
1
1
# try/catch catches more than it should #1859
"foo" | try ((try . catch "caught too much") | error) catch "caught just right"
null
"caught just right"
.[]|(try (if .=="hi" then . else error end) catch empty) | "\(.) there!"
["hi","ho"]
"hi there!"
try (["hi","ho"]|.[]|(try . catch (if .=="ho" then "BROKEN"|error else empty end)) | if .=="ho" then error else "\(.) there!" end) catch "caught outside \(.)"
null
"hi there!"
"caught outside ho"
.[]|(try . catch (if .=="ho" then "BROKEN"|error else empty end)) | if .=="ho" then error else "\(.) there!" end
["hi","ho"]
"hi there!"
try (try error catch "inner catch \(.)") catch "outer catch \(.)"
"foo"
"inner catch foo"
try ((try error catch "inner catch \(.)")|error) catch "outer catch \(.)"
"foo"
"outer catch inner catch foo"
# Also #1859, but from #1885
first(.?,.?)
null
null
# Also #1859, but from #2140
{foo: "bar"} | .foo |= .?
null
{"foo": "bar"}
# Also #1859, but from #2220
. |= try 2
1
2
. |= try 2 catch 3
1
2
.[] |= try tonumber
["1", "2a", "3", " 4", "5 ", "6.7", ".89", "-876", "+5.43", 21]
[1, 3, 6.7, 0.89, -876, 5.43, 21]
# Also 1859, but from 2073
any(keys[]|tostring?;true)
{"a":"1","b":"2","c":"3"}
true
# explode/implode
# test replacement character (65533) for outside codepoint range and 0xd800 (55296) - 0xdfff (57343) utf16 surrogate pair range
# 1.1 and 1.9 to test round down of non-ints
implode|explode
[-1,0,1,2,3,1114111,1114112,55295,55296,57343,57344,1.1,1.9]
[65533,0,1,2,3,1114111,65533,55295,65533,65533,57344,1,1]
map(try implode catch .)
[123,["a"],[nan]]
["implode input must be an array","string (\"a\") can't be imploded, unicode codepoint needs to be numeric","number (null) can't be imploded, unicode codepoint needs to be numeric"]
try 0[implode] catch .
[]
"Cannot index number with string (\"\")"
# walk
walk(.)
{"x":0}
{"x":0}
walk(1)
{"x":0}
1
# The following is a regression test, not a requirement:
[walk(.,1)]
{"x":0}
[{"x":0},1]
# Issue #2584
walk(select(IN({}, []) | not))
{"a":1,"b":[]}
{"a":1}
# #2815
[range(10)] | .[1.2:3.5]
null
[1,2,3]
[range(10)] | .[1.5:3.5]
null
[1,2,3]
[range(10)] | .[1.7:3.5]
null
[1,2,3]
[range(10)] | .[1.7:4294967295]
null
[1,2,3,4,5,6,7,8,9]
[range(10)] | .[1.7:-4294967296]
null
[]
[[range(10)] | .[1.1,1.5,1.7]]
null
[1,1,1]
[range(5)] | .[1.1] = 5
null
[0,5,2,3,4]
[range(3)] | .[nan:1]
null
[0]
[range(3)] | .[1:nan]
null
[1,2]
[range(3)] | .[nan]
null
null
try ([range(3)] | .[nan] = 9) catch .
null
"Cannot set array element at NaN index"
try ("foobar" | .[1.5:3.5] = "xyz") catch .
null
"Cannot update string slices"
try ([range(10)] | .[1.5:3.5] = ["xyz"]) catch .
null
[0,"xyz",4,5,6,7,8,9]
try ("foobar" | .[1.5]) catch .
null
"Cannot index string with number (1.5)"
# setpath/2 does not leak the input after an invalid get #2970
try ["ok", setpath([1]; 1)] catch ["ko", .]
{"hi":"hello"}
["ko","Cannot index object with number (1)"]
try fromjson catch .
"{'a': 123}"
"Invalid string literal; expected \", but got ' at line 1, column 5 (while parsing '{'a': 123}')"
# ltrimstr/1 rtrimstr/1 don't leak on invalid input #2977
try ltrimstr(1) catch "x", try rtrimstr(1) catch "x" | "ok"
"hi"
"ok"
"ok"
try ltrimstr("x") catch "x", try rtrimstr("x") catch "x" | "ok"
{"hey":[]}
"ok"
"ok"
# ltrimstr/1 and rtrimstr/1 return an error for non-strings. #2969
.[] as [$x, $y] | try ["ok", ($x | ltrimstr($y))] catch ["ko", .]
[["hi",1],[1,"hi"],["hi","hi"],[1,1]]
["ko","startswith() requires string inputs"]
["ko","startswith() requires string inputs"]
["ok",""]
["ko","startswith() requires string inputs"]
.[] as [$x, $y] | try ["ok", ($x | rtrimstr($y))] catch ["ko", .]
[["hi",1],[1,"hi"],["hi","hi"],[1,1]]
["ko","endswith() requires string inputs"]
["ko","endswith() requires string inputs"]
["ok",""]
["ko","endswith() requires string inputs"]
# oss-fuzz #66061: setpath/2 leaks when indexing array with array
try ["OK", setpath([[1]]; 1)] catch ["KO", .]
[]
["KO","Cannot update field at array index of array"]
# regression test for #3227
foreach .[] as $x (0, 1; . + $x)
[1, 2]
1
3
2
4
# regression test for CVE-2025-49014 (use of fmt after free)
# tests with both empty string literal and empty string created by function
# as they seems to behave reference wise differently.
strflocaltime("" | ., @uri)
0
""
""
# regression tests for #3413
# upper range bounds should be in sync with the constants defined at
# src/jv_parse.c:#define MAX_PARSING_DEPTH (N)
# src/jv_print.c:#define MAX_PRINT_DEPTH (N)
# (N-1)
reduce range(9999) as $_ ([];[.]) | tojson | fromjson | flatten
null
[]
# (N)
reduce range(10000) as $_ ([];[.]) | tojson | try (fromjson) catch . | (contains("<skipped: too deep>") | not) and contains("Exceeds depth limit for parsing")
null
true
# (N+1)
reduce range(10001) as $_ ([];[.]) | tojson | contains("<skipped: too deep>")
null
true
# regression test for CVE-2026-33947
setpath([range(10000) | 0]; 0) | flatten
null
[0]
try setpath([range(10001) | 0]; 0) catch .
null
"Path too deep"
getpath([range(10000) | 0])
null
null
try getpath([range(10001) | 0]) catch .
null
"Path too deep"
delpaths([[range(10000) | 0]])
null
null
try delpaths([[range(10001) | 0]]) catch .
null
"Path too deep"
# regression test for CVE-2026-40612
reduce range(10000) as $_ ([]; [.]) | contains([[]])
null
true
try (reduce range(10001) as $_ ([]; [.]) as $x | $x | contains($x)) catch .
null
"Containment check too deep"
# regression test for CVE-2026-43896
reduce range(10000) as $_ ({}; {a: .}) as $x | $x * $x | length
null
1
try (reduce range(10001) as $_ ({}; {a: .}) as $x | $x * $x) catch .
null
"Object merge too deep"
# regression test for deep structural equality recursion
try ((reduce range(10001) as $_ ([]; [.])) as $x | (reduce range(10001) as $_ ([]; [.])) as $y | $x == $y) catch .
null
"Equality check too deep"
# regression tests for deep ordering comparisons
try ((reduce range(10001) as $_ ([]; [.])) as $x | [$x, $x] | sort) catch .
null
"Comparison too deep"
try ((reduce range(10001) as $_ ([]; [.])) as $x | [$x, $x] | unique) catch .
null
"Comparison too deep"
try ((reduce range(10001) as $_ ({}; {a: .})) as $x | [$x, $x] | sort) catch .
null
"Comparison too deep"
try ((reduce range(10001) as $_ ({}; {a: .})) as $x | [$x, $x] | unique) catch .
null
"Comparison too deep"</pblock>
<pblock filename="sources/lexer.l" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/lexer.l">
%{
#include <assert.h>
#include "jv_alloc.h"
#include "compile.h"
struct lexer_param;
#include "parser.h" /* Generated by bison. */
#define YY_USER_ACTION \
do { \
yylloc->start = yyget_extra(yyscanner); \
yylloc->end = yylloc->start + yyleng; \
yyset_extra(yylloc->end, yyscanner); \
} while (0);
%}
%s IN_PAREN
%s IN_BRACKET
%s IN_BRACE
%s IN_QQINTERP
%x IN_QQSTRING
%x IN_COMMENT
%{
static int enter(int opening, int state, yyscan_t yyscanner);
static int try_exit(int closing, int state, yyscan_t yyscanner);
%}
%option noyywrap nounput noinput nodefault
%option noyyalloc noyyrealloc noyyfree
%option reentrant
%option extra-type="int"
%option bison-bridge bison-locations
%option prefix="jq_yy"
%option stack
%%
"#" { yy_push_state(IN_COMMENT, yyscanner); }
<IN_COMMENT>{
\\(\\|\r?\n)|. { }
\r?\n { yy_pop_state(yyscanner); }
}
<IN_COMMENT><<EOF>> { yy_pop_state(yyscanner); }
"!=" { return NEQ; }
"==" { return EQ; }
"as" { return AS; }
"import" { return IMPORT; }
"include" { return INCLUDE; }
"module" { return MODULE; }
"def" { return DEF; }
"if" { return IF; }
"then" { return THEN; }
"else" { return ELSE; }
"elif" { return ELSE_IF; }
"and" { return AND; }
"or" { return OR; }
"end" { return END; }
"reduce" { return REDUCE; }
"foreach" { return FOREACH; }
"//" { return DEFINEDOR; }
"try" { return TRY; }
"catch" { return CATCH; }
"label" { return LABEL; }
"break" { return BREAK; }
"$__loc__" { return LOC; }
"|=" { return SETPIPE; }
"+=" { return SETPLUS; }
"-=" { return SETMINUS; }
"*=" { return SETMULT; }
"/=" { return SETDIV; }
"%=" { return SETMOD; }
"//=" { return SETDEFINEDOR; }
"<=" { return LESSEQ; }
">=" { return GREATEREQ; }
".." { return REC; }
"?//" { return ALTERNATION; }
"."|"?"|"="|";"|","|":"|"|"|"+"|"-"|"*"|"/"|"%"|"\$"|"<"|">" { return yytext[0];}
"["|"{"|"(" {
return enter(yytext[0], YY_START, yyscanner);
}
"]"|"}"|")" {
return try_exit(yytext[0], YY_START, yyscanner);
}
"@"[a-zA-Z0-9_]+ {
yylval->literal = jv_string_sized(yytext + 1, yyleng - 1); return FORMAT;
}
([0-9]+(\.[0-9]*)?|\.[0-9]+)([eE][+-]?[0-9]+)? {
yylval->literal = jv_parse_sized(yytext, yyleng); return LITERAL;
}
"\"" {
yy_push_state(IN_QQSTRING, yyscanner);
return QQSTRING_START;
}
<IN_QQSTRING>{
"\\(" {
return enter(QQSTRING_INTERP_START, YY_START, yyscanner);
}
"\"" {
yy_pop_state(yyscanner);
return QQSTRING_END;
}
(\\[^u(]|\\u[a-zA-Z0-9]{0,4})+ {
/* pass escapes to the json parser */
jv escapes = jv_string_fmt("\"%.*s\"", (int)yyleng, yytext);
yylval->literal = jv_parse_sized(jv_string_value(escapes), jv_string_length_bytes(jv_copy(escapes)));
jv_free(escapes);
return QQSTRING_TEXT;
}
[^\\\"]+ {
yylval->literal = jv_string_sized(yytext, yyleng);
return QQSTRING_TEXT;
}
. {
return INVALID_CHARACTER;
}
}
([a-zA-Z_][a-zA-Z_0-9]*::)*[a-zA-Z_][a-zA-Z_0-9]* { yylval->literal = jv_string(yytext); return IDENT;}
\.[a-zA-Z_][a-zA-Z_0-9]* { yylval->literal = jv_string(yytext+1); return FIELD;}
\$([a-zA-Z_][a-zA-Z_0-9]*::)*[a-zA-Z_][a-zA-Z_0-9]* { yylval->literal = jv_string(yytext+1); return BINDING;}
[ \r\n\t]+ {}
. { return INVALID_CHARACTER; }
%%
/* perhaps these should be calls... */
/*
"true" { return TRUE; }
"false" { return FALSE; }
"null" { return NULL; }
*/
static int try_exit(int c, int state, yyscan_t yyscanner) {
char match = 0;
int ret;
switch (state) {
case IN_PAREN: match = ret = ')'; break;
case IN_BRACKET: match = ret = ']'; break;
case IN_BRACE: match = ret = '}'; break;
case IN_QQINTERP:
match = ')';
ret = QQSTRING_INTERP_END;
break;
default:
// may not be the best error to give
return INVALID_CHARACTER;
}
assert(match);
if (match == c) {
yy_pop_state(yyscanner);
return ret;
} else {
// FIXME: should we pop? Give a better error at least
return INVALID_CHARACTER;
}
}
static int enter(int c, int currstate, yyscan_t yyscanner) {
int state = 0;
switch (c) {
case '(': state = IN_PAREN; break;
case '[': state = IN_BRACKET; break;
case '{': state = IN_BRACE; break;
case QQSTRING_INTERP_START: state = IN_QQINTERP; break;
}
assert(state);
yy_push_state(state, yyscanner);
return c;
}
void* yyalloc(size_t sz, void* extra) {
return jv_mem_alloc(sz);
}
void* yyrealloc(void* p, size_t sz, void* extra) {
return jv_mem_realloc(p, sz);
}
void yyfree(void* p, void* extra) {
jv_mem_free(p);
}</pblock>
<pblock filename="sources/parser.y" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/parser.y">
%{
#include <assert.h>
#include <math.h>
#include <stdio.h>
#include <string.h>
#include "compile.h"
#include "jv_alloc.h"
#include "builtin.h"
#define YYMALLOC jv_mem_alloc
#define YYFREE jv_mem_free
%}
%code requires {
#include "locfile.h"
struct lexer_param;
#define YYLTYPE location
#define YYLLOC_DEFAULT(Loc, Rhs, N) \
do { \
if (N) { \
(Loc).start = YYRHSLOC(Rhs, 1).start; \
(Loc).end = YYRHSLOC(Rhs, N).end; \
} else { \
(Loc).start = YYRHSLOC(Rhs, 0).end; \
(Loc).end = YYRHSLOC(Rhs, 0).end; \
} \
} while (0)
}
%locations
%define parse.error verbose
%define api.pure
%union {
jv literal;
block blk;
}
%destructor { jv_free($$); } <literal>
%destructor { block_free($$); } <blk>
%parse-param {block* answer}
%parse-param {int* errors}
%parse-param {struct locfile* locations}
%parse-param {struct lexer_param* lexer_param_ptr}
%lex-param {block* answer}
%lex-param {int* errors}
%lex-param {struct locfile* locations}
%lex-param {struct lexer_param* lexer_param_ptr}
%token INVALID_CHARACTER
%token <literal> IDENT
%token <literal> FIELD
%token <literal> BINDING
%token <literal> LITERAL
%token <literal> FORMAT
%token REC ".."
%token SETMOD "%="
%token EQ "=="
%token NEQ "!="
%token DEFINEDOR "//"
%token AS "as"
%token DEF "def"
%token MODULE "module"
%token IMPORT "import"
%token INCLUDE "include"
%token IF "if"
%token THEN "then"
%token ELSE "else"
%token ELSE_IF "elif"
%token REDUCE "reduce"
%token FOREACH "foreach"
%token END "end"
%token AND "and"
%token OR "or"
%token TRY "try"
%token CATCH "catch"
%token LABEL "label"
%token BREAK "break"
%token LOC "$__loc__"
%token SETPIPE "|="
%token SETPLUS "+="
%token SETMINUS "-="
%token SETMULT "*="
%token SETDIV "/="
%token SETDEFINEDOR "//="
%token LESSEQ "<="
%token GREATEREQ ">="
%token ALTERNATION "?//"
%token QQSTRING_START
%token <literal> QQSTRING_TEXT
%token QQSTRING_INTERP_START
%token QQSTRING_INTERP_END
%token QQSTRING_END
/* Instead of raising this, find a way to use precedence to resolve
* shift-reduce conflicts. */
%expect 0
%precedence FUNCDEF
%right '|'
%left ','
%right "//"
%nonassoc '=' SETPIPE SETPLUS SETMINUS SETMULT SETDIV SETMOD SETDEFINEDOR
%left OR
%left AND
%nonassoc NEQ EQ '<' '>' LESSEQ GREATEREQ
%left '+' '-'
%left '*' '/' '%'
%precedence NONOPT /* non-optional; rules for which a specialized
'?' rule should be preferred over Expr '?' */
%precedence '?' '.' '[' FIELD
%precedence "try"
%precedence "catch"
%type <blk> Query Expr Term
%type <blk> DictPairs DictPair DictExpr
%type <blk> ElseBody
%type <blk> String QQString
%type <blk> FuncDef FuncDefs
%type <blk> Module Import Imports ImportWhat ImportFrom
%type <blk> Param Params Arg Args
%type <blk> Patterns RepPatterns Pattern ArrayPats ObjPats ObjPat
%type <literal> Keyword
%type <literal> StringStart
%{
#include "lexer.h"
struct lexer_param {
yyscan_t lexer;
};
#define FAIL(loc, msg) \
do { \
location l = loc; \
yyerror(&l, answer, errors, locations, lexer_param_ptr, msg); \
/*YYERROR*/; \
} while (0)
void yyerror(YYLTYPE* loc, block* answer, int* errors,
struct locfile* locations, struct lexer_param* lexer_param_ptr, const char *s){
(*errors)++;
locfile_locate(locations, *loc, "jq: error: %s", s);
}
int yylex(YYSTYPE* yylval, YYLTYPE* yylloc, block* answer, int* errors,
struct locfile* locations, struct lexer_param* lexer_param_ptr) {
yyscan_t lexer = lexer_param_ptr->lexer;
int tok = jq_yylex(yylval, yylloc, lexer);
if ((tok == LITERAL || tok == QQSTRING_TEXT) && !jv_is_valid(yylval->literal)) {
jv msg = jv_invalid_get_msg(jv_copy(yylval->literal));
if (jv_get_kind(msg) == JV_KIND_STRING) {
FAIL(*yylloc, jv_string_value(msg));
} else {
FAIL(*yylloc, "Invalid literal");
}
jv_free(msg);
jv_free(yylval->literal);
yylval->literal = jv_null();
}
return tok;
}
/* Returns string message if the block is a constant that is not valid as an
* object key. */
static jv check_object_key(block k) {
if (block_is_const(k) && block_const_kind(k) != JV_KIND_STRING) {
char errbuf[30];
return jv_string_fmt("Cannot use %s (%s) as object key",
jv_kind_name(block_const_kind(k)),
jv_dump_string_trunc(block_const(k), errbuf, sizeof(errbuf)));
}
return jv_invalid();
}
static block gen_index(block obj, block key) {
return BLOCK(gen_subexp(key), obj, gen_op_simple(INDEX));
}
static block gen_index_opt(block obj, block key) {
return BLOCK(gen_subexp(key), obj, gen_op_simple(INDEX_OPT));
}
static block gen_slice_index(block obj, block start, block end, opcode idx_op) {
block key = BLOCK(gen_subexp(gen_const(jv_object())),
gen_subexp(gen_const(jv_string("start"))),
gen_subexp(start),
gen_op_simple(INSERT),
gen_subexp(gen_const(jv_string("end"))),
gen_subexp(end),
gen_op_simple(INSERT));
return BLOCK(key, obj, gen_op_simple(idx_op));
}
static block constant_fold(block a, block b, int op) {
if (!block_is_single(a) || !block_is_const(a) ||
!block_is_single(b) || !block_is_const(b))
return gen_noop();
jv jv_a = block_const(a);
block_free(a);
jv jv_b = block_const(b);
block_free(b);
jv res = jv_invalid();
switch (op) {
case '+': res = binop_plus(jv_a, jv_b); break;
case '-': res = binop_minus(jv_a, jv_b); break;
case '*': res = binop_multiply(jv_a, jv_b); break;
case '/': res = binop_divide(jv_a, jv_b); break;
case '%': res = binop_mod(jv_a, jv_b); break;
case EQ: res = binop_equal(jv_a, jv_b); break;
case NEQ: res = binop_notequal(jv_a, jv_b); break;
case '<': res = binop_less(jv_a, jv_b); break;
case '>': res = binop_greater(jv_a, jv_b); break;
case LESSEQ: res = binop_lesseq(jv_a, jv_b); break;
case GREATEREQ: res = binop_greatereq(jv_a, jv_b); break;
}
if (jv_is_valid(res))
return gen_const(res);
return gen_error(jv_invalid_get_msg(res));
}
static block gen_binop(block a, block b, int op) {
block folded = constant_fold(a, b, op);
if (!block_is_noop(folded))
return folded;
const char* funcname = 0;
switch (op) {
case '+': funcname = "_plus"; break;
case '-': funcname = "_minus"; break;
case '*': funcname = "_multiply"; break;
case '/': funcname = "_divide"; break;
case '%': funcname = "_mod"; break;
case EQ: funcname = "_equal"; break;
case NEQ: funcname = "_notequal"; break;
case '<': funcname = "_less"; break;
case '>': funcname = "_greater"; break;
case LESSEQ: funcname = "_lesseq"; break;
case GREATEREQ: funcname = "_greatereq"; break;
}
assert(funcname);
return gen_call(funcname, BLOCK(gen_lambda(a), gen_lambda(b)));
}
static block gen_format(block a, jv fmt) {
return BLOCK(a, gen_call("format", gen_lambda(gen_const(fmt))));
}
static block gen_definedor_assign(block object, block val) {
block tmp = gen_op_var_fresh(STOREV, "tmp");
return BLOCK(gen_op_simple(DUP),
val, tmp,
gen_call("_modify", BLOCK(gen_lambda(object),
gen_lambda(gen_definedor(gen_noop(),
gen_op_bound(LOADV, tmp))))));
}
static block gen_update(block object, block val, int optype) {
block tmp = gen_op_var_fresh(STOREV, "tmp");
return BLOCK(gen_op_simple(DUP),
val,
tmp,
gen_call("_modify", BLOCK(gen_lambda(object),
gen_lambda(gen_binop(gen_noop(),
gen_op_bound(LOADV, tmp),
optype)))));
}
static block gen_loc_object(location *loc, struct locfile *locations) {
return gen_const(JV_OBJECT(jv_string("file"), jv_copy(locations->fname),
jv_string("line"), jv_number(locfile_get_line(locations, loc->start) + 1)));
}
%}
%%
TopLevel:
Module Imports Query {
*answer = BLOCK($1, $2, gen_op_simple(TOP), $3);
} |
Module Imports FuncDefs {
*answer = BLOCK($1, $2, $3);
}
Module:
%empty {
$$ = gen_noop();
} |
"module" Query ';' {
if (!block_is_const($2)) {
FAIL(@2, "Module metadata must be constant");
$$ = gen_noop();
block_free($2);
} else if (block_const_kind($2) != JV_KIND_OBJECT) {
FAIL(@2, "Module metadata must be an object");
$$ = gen_noop();
block_free($2);
} else {
$$ = gen_module($2);
}
}
Imports:
%empty {
$$ = gen_noop();
} |
Import Imports {
$$ = BLOCK($1, $2);
}
FuncDefs:
%empty {
$$ = gen_noop();
} |
FuncDef FuncDefs {
$$ = block_join($1, $2);
}
Query:
FuncDef Query %prec FUNCDEF {
$$ = block_bind_referenced($1, $2, OP_IS_CALL_PSEUDO);
} |
Expr "as" Patterns '|' Query {
$$ = gen_destructure($1, $3, $5);
} |
"label" BINDING '|' Query {
jv v = jv_string_fmt("*label-%s", jv_string_value($2));
$$ = gen_location(@$, locations, gen_label(jv_string_value(v), $4));
jv_free($2);
jv_free(v);
} |
Query '|' Query {
$$ = block_join($1, $3);
} |
Query ',' Query {
$$ = gen_both($1, $3);
} |
Expr {
$$ = $1;
}
Expr:
Expr "//" Expr {
$$ = gen_definedor($1, $3);
} |
Expr '=' Expr {
$$ = gen_call("_assign", BLOCK(gen_lambda($1), gen_lambda($3)));
} |
Expr "or" Expr {
$$ = gen_or($1, $3);
} |
Expr "and" Expr {
$$ = gen_and($1, $3);
} |
Expr "//=" Expr {
$$ = gen_definedor_assign($1, $3);
} |
Expr "|=" Expr {
$$ = gen_call("_modify", BLOCK(gen_lambda($1), gen_lambda($3)));
} |
Expr '+' Expr {
$$ = gen_binop($1, $3, '+');
} |
Expr "+=" Expr {
$$ = gen_update($1, $3, '+');
} |
Expr '-' Expr {
$$ = gen_binop($1, $3, '-');
} |
Expr "-=" Expr {
$$ = gen_update($1, $3, '-');
} |
Expr '*' Expr {
$$ = gen_binop($1, $3, '*');
} |
Expr "*=" Expr {
$$ = gen_update($1, $3, '*');
} |
Expr '/' Expr {
$$ = gen_binop($1, $3, '/');
} |
Expr '%' Expr {
$$ = gen_binop($1, $3, '%');
} |
Expr "/=" Expr {
$$ = gen_update($1, $3, '/');
} |
Expr SETMOD Expr {
$$ = gen_update($1, $3, '%');
} |
Expr "==" Expr {
$$ = gen_binop($1, $3, EQ);
} |
Expr "!=" Expr {
$$ = gen_binop($1, $3, NEQ);
} |
Expr '<' Expr {
$$ = gen_binop($1, $3, '<');
} |
Expr '>' Expr {
$$ = gen_binop($1, $3, '>');
} |
Expr "<=" Expr {
$$ = gen_binop($1, $3, LESSEQ);
} |
Expr ">=" Expr {
$$ = gen_binop($1, $3, GREATEREQ);
} |
Term %prec NONOPT {
$$ = $1;
}
Import:
ImportWhat ';' {
$$ = $1;
} |
ImportWhat Query ';' {
if (!block_is_const($2)) {
FAIL(@2, "Module metadata must be constant");
$$ = gen_noop();
block_free($1);
block_free($2);
} else if (block_const_kind($2) != JV_KIND_OBJECT) {
FAIL(@2, "Module metadata must be an object");
$$ = gen_noop();
block_free($1);
block_free($2);
} else {
$$ = gen_import_meta($1, $2);
}
}
ImportWhat:
"import" ImportFrom "as" BINDING {
$$ = gen_import(block_const($2), $4, 1);
block_free($2);
} |
"import" ImportFrom "as" IDENT {
$$ = gen_import(block_const($2), $4, 0);
block_free($2);
} |
"include" ImportFrom {
$$ = gen_import(block_const($2), jv_invalid(), 0);
block_free($2);
}
ImportFrom:
String {
if (!block_is_const($1)) {
FAIL(@1, "Import path must be constant");
$$ = gen_const(jv_string(""));
block_free($1);
} else {
$$ = $1;
}
}
FuncDef:
"def" IDENT ':' Query ';' {
$$ = gen_function(jv_string_value($2), gen_noop(), $4);
jv_free($2);
} |
"def" IDENT '(' Params ')' ':' Query ';' {
$$ = gen_function(jv_string_value($2), $4, $7);
jv_free($2);
}
Params:
Param {
$$ = $1;
} |
Params ';' Param {
$$ = BLOCK($1, $3);
}
Param:
BINDING {
$$ = gen_param_regular(jv_string_value($1));
jv_free($1);
} |
IDENT {
$$ = gen_param(jv_string_value($1));
jv_free($1);
}
StringStart:
FORMAT QQSTRING_START {
$$ = $1;
} |
QQSTRING_START {
$$ = jv_string("text");
}
String:
StringStart QQString QQSTRING_END {
$$ = $2;
jv_free($1);
};
QQString:
%empty {
$$ = gen_const(jv_string(""));
} |
QQString QQSTRING_TEXT {
$$ = gen_binop($1, gen_const($2), '+');
} |
QQString QQSTRING_INTERP_START Query QQSTRING_INTERP_END {
$$ = gen_binop($1, gen_format($3, jv_copy($<literal>0)), '+');
}
ElseBody:
"elif" Query "then" Query ElseBody {
$$ = gen_cond($2, $4, $5);
} |
"else" Query "end" {
$$ = $2;
} |
"end" {
$$ = gen_noop();
}
Term:
'.' {
$$ = gen_noop();
} |
REC {
$$ = gen_call("recurse", gen_noop());
} |
BREAK BINDING {
jv v = jv_string_fmt("*label-%s", jv_string_value($2)); // impossible symbol
$$ = gen_location(@$, locations,
BLOCK(gen_op_unbound(LOADV, jv_string_value(v)),
gen_call("error", gen_noop())));
jv_free(v);
jv_free($2);
} |
BREAK error {
FAIL(@$, "break requires a label to break to");
$$ = gen_noop();
} |
Term FIELD '?' {
$$ = gen_index_opt($1, gen_const($2));
} |
FIELD '?' {
$$ = gen_index_opt(gen_noop(), gen_const($1));
} |
Term '.' String '?' {
$$ = gen_index_opt($1, $3);
} |
'.' String '?' {
$$ = gen_index_opt(gen_noop(), $2);
} |
Term FIELD %prec NONOPT {
$$ = gen_index($1, gen_const($2));
} |
FIELD %prec NONOPT {
$$ = gen_index(gen_noop(), gen_const($1));
} |
Term '.' String %prec NONOPT {
$$ = gen_index($1, $3);
} |
'.' String %prec NONOPT {
$$ = gen_index(gen_noop(), $2);
} |
'.' error {
FAIL(@$, "try .[\"field\"] instead of .field for unusually named fields");
$$ = gen_noop();
} |
'.' IDENT error {
jv_free($2);
FAIL(@$, "try .[\"field\"] instead of .field for unusually named fields");
$$ = gen_noop();
} |
/* FIXME: string literals */
Term '[' Query ']' '?' {
$$ = gen_index_opt($1, $3);
} |
Term '[' Query ']' %prec NONOPT {
$$ = gen_index($1, $3);
} |
Term '.' '[' Query ']' '?' {
$$ = gen_index_opt($1, $4);
} |
Term '.' '[' Query ']' %prec NONOPT {
$$ = gen_index($1, $4);
} |
Term '[' ']' '?' {
$$ = block_join($1, gen_op_simple(EACH_OPT));
} |
Term '[' ']' %prec NONOPT {
$$ = block_join($1, gen_op_simple(EACH));
} |
Term '.' '[' ']' '?' {
$$ = block_join($1, gen_op_simple(EACH_OPT));
} |
Term '.' '[' ']' %prec NONOPT {
$$ = block_join($1, gen_op_simple(EACH));
} |
Term '[' Query ':' Query ']' '?' {
$$ = gen_slice_index($1, $3, $5, INDEX_OPT);
} |
Term '[' Query ':' ']' '?' {
$$ = gen_slice_index($1, $3, gen_const(jv_null()), INDEX_OPT);
} |
Term '[' ':' Query ']' '?' {
$$ = gen_slice_index($1, gen_const(jv_null()), $4, INDEX_OPT);
} |
Term '[' Query ':' Query ']' %prec NONOPT {
$$ = gen_slice_index($1, $3, $5, INDEX);
} |
Term '[' Query ':' ']' %prec NONOPT {
$$ = gen_slice_index($1, $3, gen_const(jv_null()), INDEX);
} |
Term '[' ':' Query ']' %prec NONOPT {
$$ = gen_slice_index($1, gen_const(jv_null()), $4, INDEX);
} |
Term '?' {
$$ = gen_try($1, gen_op_simple(BACKTRACK));
} |
LITERAL {
$$ = gen_const($1);
} |
String {
$$ = $1;
} |
FORMAT {
$$ = gen_format(gen_noop(), $1);
} |
'-' Term {
$$ = BLOCK($2, gen_call("_negate", gen_noop()));
} |
'(' Query ')' {
$$ = $2;
} |
'[' Query ']' {
$$ = gen_collect($2);
} |
'[' ']' {
$$ = gen_const(jv_array());
} |
'{' DictPairs '}' {
block o = gen_const_object($2);
if (o.first != NULL)
$$ = o;
else
$$ = BLOCK(gen_subexp(gen_const(jv_object())), $2, gen_op_simple(POP));
} |
"reduce" Expr "as" Patterns '(' Query ';' Query ')' {
$$ = gen_reduce($2, $4, $6, $8);
} |
"foreach" Expr "as" Patterns '(' Query ';' Query ';' Query ')' {
$$ = gen_foreach($2, $4, $6, $8, $10);
} |
"foreach" Expr "as" Patterns '(' Query ';' Query ')' {
$$ = gen_foreach($2, $4, $6, $8, gen_noop());
} |
"if" Query "then" Query ElseBody {
$$ = gen_cond($2, $4, $5);
} |
"if" Query "then" error {
FAIL(@$, "Possibly unterminated 'if' statement");
$$ = $2;
} |
"try" Expr "catch" Expr {
$$ = gen_try($2, $4);
} |
"try" Expr "catch" error {
FAIL(@$, "Possibly unterminated 'try' statement");
$$ = $2;
} |
"try" Expr {
$$ = gen_try($2, gen_op_simple(BACKTRACK));
} |
/*
* This `$$$$varname` hack is strictly private to jq builtins. DO NOT USE!!
*
* This is used in `_modify`, in src/builtin.jq, to avoid holding on to a
* reference to `.`.
*
* We could just have the compiler emit bytecode for `_modify` so it can use
* LOADVN w/o needing jq syntax for LOADVN.
*
* This syntax, `$$$$varname`, violates referential transparency: it has
* side-effects that are surprising.
*
* DO NOT USE!! I will break your jq code if you do use this outside
* src/builtin.jq.
*/
'$' '$' '$' BINDING {
$$ = gen_location(@$, locations, gen_op_unbound(LOADVN, jv_string_value($4)));
jv_free($4);
} |
BINDING {
$$ = gen_location(@$, locations, gen_op_unbound(LOADV, jv_string_value($1)));
jv_free($1);
} |
"$__loc__" {
$$ = gen_loc_object(&@$, locations);
} |
IDENT {
const char *s = jv_string_value($1);
if (strcmp(s, "false") == 0)
$$ = gen_const(jv_false());
else if (strcmp(s, "true") == 0)
$$ = gen_const(jv_true());
else if (strcmp(s, "null") == 0)
$$ = gen_const(jv_null());
else
$$ = gen_location(@$, locations, gen_call(s, gen_noop()));
jv_free($1);
} |
IDENT '(' Args ')' {
$$ = gen_call(jv_string_value($1), $3);
$$ = gen_location(@1, locations, $$);
jv_free($1);
} |
'(' error ')' { $$ = gen_noop(); } |
'[' error ']' { $$ = gen_noop(); } |
Term '[' error ']' { $$ = $1; } |
'{' error '}' { $$ = gen_noop(); }
Args:
Arg {
$$ = $1;
} |
Args ';' Arg {
$$ = BLOCK($1, $3);
}
Arg:
Query {
$$ = gen_lambda($1);
}
RepPatterns:
RepPatterns "?//" Pattern {
$$ = BLOCK($1, gen_destructure_alt($3));
} |
Pattern {
$$ = gen_destructure_alt($1);
}
Patterns:
RepPatterns "?//" Pattern {
$$ = BLOCK($1, $3);
} |
Pattern {
$$ = $1;
}
Pattern:
BINDING {
$$ = gen_op_unbound(STOREV, jv_string_value($1));
jv_free($1);
} |
'[' ArrayPats ']' {
$$ = BLOCK($2, gen_op_simple(POP));
} |
'{' ObjPats '}' {
$$ = BLOCK($2, gen_op_simple(POP));
}
ArrayPats:
Pattern {
$$ = gen_array_matcher(gen_noop(), $1);
} |
ArrayPats ',' Pattern {
$$ = gen_array_matcher($1, $3);
}
ObjPats:
ObjPat {
$$ = $1;
} |
ObjPats ',' ObjPat {
$$ = BLOCK($1, $3);
}
ObjPat:
BINDING {
$$ = gen_object_matcher(gen_const($1), gen_op_unbound(STOREV, jv_string_value($1)));
} |
BINDING ':' Pattern {
$$ = gen_object_matcher(gen_const($1), BLOCK(gen_op_simple(DUP), gen_op_unbound(STOREV, jv_string_value($1)), $3));
} |
IDENT ':' Pattern {
$$ = gen_object_matcher(gen_const($1), $3);
} |
Keyword ':' Pattern {
$$ = gen_object_matcher(gen_const($1), $3);
} |
String ':' Pattern {
$$ = gen_object_matcher($1, $3);
} |
'(' Query ')' ':' Pattern {
jv msg = check_object_key($2);
if (jv_is_valid(msg)) {
FAIL(@2, jv_string_value(msg));
}
jv_free(msg);
$$ = gen_object_matcher($2, $5);
} |
error ':' Pattern {
FAIL(@$, "May need parentheses around object key expression");
$$ = $3;
}
Keyword:
"as" {
$$ = jv_string("as");
} |
"def" {
$$ = jv_string("def");
} |
"module" {
$$ = jv_string("module");
} |
"import" {
$$ = jv_string("import");
} |
"include" {
$$ = jv_string("include");
} |
"if" {
$$ = jv_string("if");
} |
"then" {
$$ = jv_string("then");
} |
"else" {
$$ = jv_string("else");
} |
"elif" {
$$ = jv_string("elif");
} |
"reduce" {
$$ = jv_string("reduce");
} |
"foreach" {
$$ = jv_string("foreach");
} |
"end" {
$$ = jv_string("end");
} |
"and" {
$$ = jv_string("and");
} |
"or" {
$$ = jv_string("or");
} |
"try" {
$$ = jv_string("try");
} |
"catch" {
$$ = jv_string("catch");
} |
"label" {
$$ = jv_string("label");
} |
"break" {
$$ = jv_string("break");
}
DictPairs:
%empty {
$$ = gen_noop();
} |
DictPair {
$$ = $1;
} |
DictPair ',' DictPairs {
$$ = block_join($1, $3);
}
DictPair:
IDENT ':' DictExpr {
$$ = gen_dictpair(gen_const($1), $3);
} |
Keyword ':' DictExpr {
$$ = gen_dictpair(gen_const($1), $3);
} |
String ':' DictExpr {
$$ = gen_dictpair($1, $3);
} |
String {
$$ = gen_dictpair($1, BLOCK(gen_op_simple(POP), gen_op_simple(DUP2),
gen_op_simple(DUP2), gen_op_simple(INDEX)));
} |
BINDING ':' DictExpr {
$$ = gen_dictpair(gen_location(@$, locations, gen_op_unbound(LOADV, jv_string_value($1))),
$3);
jv_free($1);
} |
BINDING {
$$ = gen_dictpair(gen_const($1),
gen_location(@$, locations, gen_op_unbound(LOADV, jv_string_value($1))));
} |
IDENT {
$$ = gen_dictpair(gen_const(jv_copy($1)),
gen_index(gen_noop(), gen_const($1)));
} |
"$__loc__" {
$$ = gen_dictpair(gen_const(jv_string("__loc__")),
gen_loc_object(&@$, locations));
} |
Keyword {
$$ = gen_dictpair(gen_const(jv_copy($1)),
gen_index(gen_noop(), gen_const($1)));
} |
'(' Query ')' ':' DictExpr {
jv msg = check_object_key($2);
if (jv_is_valid(msg)) {
FAIL(@2, jv_string_value(msg));
}
jv_free(msg);
$$ = gen_dictpair($2, $5);
} |
error ':' DictExpr {
FAIL(@1, "May need parentheses around object key expression");
$$ = $3;
}
DictExpr:
DictExpr '|' DictExpr {
$$ = block_join($1, $3);
} |
Expr {
$$ = $1;
}
%%
int jq_parse(struct locfile* locations, block* answer) {
struct lexer_param scanner;
YY_BUFFER_STATE buf;
jq_yylex_init_extra(0, &scanner.lexer);
buf = jq_yy_scan_bytes(locations->data, locations->length, scanner.lexer);
int errors = 0;
*answer = gen_noop();
yyparse(answer, &errors, locations, &scanner);
jq_yy_delete_buffer(buf, scanner.lexer);
jq_yylex_destroy(scanner.lexer);
if (errors > 0) {
block_free(*answer);
*answer = gen_noop();
}
return errors;
}
int jq_parse_library(struct locfile* locations, block* answer) {
int errs = jq_parse(locations, answer);
if (errs) return errs;
if (block_has_main(*answer)) {
locfile_locate(locations, UNKNOWN_LOCATION, "jq: error: library should only have function definitions, not a main expression");
return 1;
}
assert(block_has_only_binders_and_imports(*answer, OP_IS_CALL_PSEUDO));
return 0;
}</pblock>
<pblock filename="sources/run_conformance.py" role="source file" path="/mnt/c/Users/barlo/projects/drydock/uat/jq/runs/20260822.044627/workspace/targets/jq/blueprint/sources/run_conformance.py">
#!/usr/bin/env python3
"""Run the upstream jq conformance corpus against a candidate implementation.
This is the scoring instrument. It is supplied, not authored: it is staged verbatim into the
build directory, hash-verified against the import, and restored before grading. Its exit status
is the acceptance verdict.
It is deliberately external to the implementation. Upstream jq grades itself, through its own
``--run-tests`` flag; a self-graded suite proves nothing here, so this runner re-implements the
corpus protocol and drives the candidate as a subprocess, one process per case.
Imported sources land in ``sources/`` inside the application directory, so this is normally
invoked as ``python3 sources/run_conformance.py`` from that directory.
Usage:
JQ=./jq python3 sources/run_conformance.py # full corpus, the scored run
JQ=./jq python3 sources/run_conformance.py -v # list passing cases too
JQ=./jq python3 sources/run_conformance.py --json # machine-readable report
JQ=./jq python3 sources/run_conformance.py --list # print cases, run nothing
JQ=./jq python3 sources/run_conformance.py --select 'reduce' # develop one construct
Environment:
JQ command that runs the candidate. Required -- this harness is language-neutral
and deliberately has no default implementation language.
Exit codes:
0 every case that ran passed
1 at least one case failed or errored
2 the harness could not run: bad usage, missing corpus, or a stale exclusion
"""
from __future__ import annotations
import argparse
import json
import os
import re
import shlex
import subprocess
import sys
from dataclasses import dataclass, field
from pathlib import Path
HERE = Path(__file__).resolve().parent
CORPUS = HERE / "jq.test"
EXCLUSIONS = HERE / "exclusions.txt"
#: A case that has not produced output in this long is not going to. jq's own suite runs the
#: whole corpus in under a second; anything near this bound is a runaway generator.
DEFAULT_TIMEOUT = 10.0
PASS, FAIL, ERROR, SKIP = "pass", "fail", "error", "skip"
#: jq's documented exit codes, which this kit's interface contract adopts. The distinction is
#: load-bearing: the corpus's %%FAIL cases are programs that must not compile, while an ordinary
#: case may legitimately raise at run time part-way through its output and still be correct.
EXIT_COMPILE_ERROR = 3
EXIT_RUNTIME_ERROR = 5
def split_lines(text: str) -> list[str]:
"""Split on newlines only.
``str.splitlines`` is Unicode-aware and also breaks on U+000B, U+000C, U+0085, U+2028, and
U+2029. The corpus contains cases whose expected output embeds those code points inside JSON
strings -- ``trim, ltrim, rtrim`` over the Unicode whitespace set is one -- and splitting
there shreds one JSON value into several, failing a correct implementation.
"""
lines = text.split("\n")
if lines and lines[-1] == "":
lines.pop()
return lines
@dataclass
class Case:
"""One corpus case: a program, an input, and what it must produce.
``expect_failure`` cases are the corpus's ``%%FAIL`` blocks. Upstream compares their
diagnostic text; this runner requires only that the candidate reject the program. The
expected strings are jq's exact C-implementation diagnostics, down to the caret art
underlining the offending token -- reproducing them is reverse-engineering an
implementation, not conforming to a specification. The text is parsed and reported so a
reader can see what upstream said, and is never compared.
"""
line: int
program: str
stdin: str = ""
expected: list[str] = field(default_factory=list)
expect_failure: bool = False
diagnostic: str = ""
@dataclass
class Result:
case: Case
status: str
detail: str = ""
actual: list[str] = field(default_factory=list)
return_code: int | None = None
stderr: str = ""
class HarnessError(Exception):
"""A fault in the kit or its invocation, never a fault in the candidate."""
# --------------------------------------------------------------------------------------------
# Corpus parsing
# --------------------------------------------------------------------------------------------
def parse_corpus(text: str) -> list[Case]:
"""Parse the jq test corpus.
The format is documented in the corpus's own header: cases are groups of lines separated by
blank lines; blank lines and lines starting with ``#`` are ignored. A case is a program
line, an input line, and then zero or more expected output lines. A case preceded by a
``%%FAIL`` or ``%%FAIL IGNORE MSG`` marker is a program line followed by the diagnostic
upstream jq emits, which may itself span several lines of source excerpt and caret art.
"""
cases: list[Case] = []
block: list[tuple[int, str]] = []
expect_failure = False
lines = split_lines(text)
def flush() -> None:
nonlocal block, expect_failure
if block:
cases.append(_case_from_block(block, expect_failure))
block = []
expect_failure = False
for number, raw in enumerate(lines, start=1):
stripped = raw.strip()
if not stripped:
flush()
continue
if raw.startswith("%%FAIL"):
flush()
expect_failure = True
continue
# A '#' comment closes nothing: upstream places section banners between cases, always
# with blank lines around them, and never inside a case.
if raw.lstrip().startswith("#") and not block:
continue
if raw.lstrip().startswith("#"):
continue
block.append((number, raw))
flush()
return cases
def _case_from_block(block: list[tuple[int, str]], expect_failure: bool) -> Case:
line, program = block[0]
if expect_failure:
diagnostic = "\n".join(text for _, text in block[1:])
return Case(line=line, program=program, expect_failure=True, diagnostic=diagnostic)
if len(block) < 2:
raise HarnessError(
f"{CORPUS.name}:{line}: case has a program but no input line; the corpus is malformed"
)
return Case(
line=line,
program=program,
stdin=block[1][1],
expected=[text for _, text in block[2:]],
)
# --------------------------------------------------------------------------------------------
# Exclusions
# --------------------------------------------------------------------------------------------
def parse_exclusions(path: Path) -> list[str]:
"""Read the declared exclusions: one verbatim program line per entry, ``#`` for reasons."""
if not path.is_file():
return []
return [
line
for line in split_lines(path.read_text(encoding="utf-8"))
if line.strip() and not line.lstrip().startswith("#")
]
def apply_exclusions(cases: list[Case], exclusions: list[str]) -> set[int]:
"""Return the corpus line numbers of excluded cases.
An exclusion that matches nothing is a hard error rather than a shrug. The corpus is pinned
by hash, so a stale exclusion means the pin moved without the exclusion list being revisited
-- and a silent no-op there would quietly re-admit a case the kit cannot run.
"""
by_program: dict[str, list[Case]] = {}
for case in cases:
by_program.setdefault(case.program, []).append(case)
excluded: set[int] = set()
stale: list[str] = []
for program in exclusions:
matched = by_program.get(program)
if not matched:
stale.append(program)
continue
excluded.update(case.line for case in matched)
if stale:
listed = "\n".join(f" {program}" for program in stale)
raise HarnessError(
f"{EXCLUSIONS.name}: these exclusions match no case in {CORPUS.name}:\n{listed}\n"
"The corpus and the exclusion list have drifted apart."
)
return excluded
# --------------------------------------------------------------------------------------------
# Comparison
# --------------------------------------------------------------------------------------------
def jv_equal(left: object, right: object) -> bool:
"""Compare two decoded JSON values the way jq's own ``jv_equal`` does.
Structural, not textual: ``1`` and ``1.0`` are the same jq value and the corpus relies on
that. Python's ``==`` almost does this, but it also equates ``True`` with ``1`` and
``False`` with ``0``, which jq does not; booleans are therefore matched by identity of type
before anything else.
"""
if isinstance(left, bool) or isinstance(right, bool):
return isinstance(left, bool) and isinstance(right, bool) and left is right
if isinstance(left, (int, float)) and isinstance(right, (int, float)):
return left == right
if isinstance(left, list) and isinstance(right, list):
return len(left) == len(right) and all(jv_equal(a, b) for a, b in zip(left, right))
if isinstance(left, dict) and isinstance(right, dict):
return left.keys() == right.keys() and all(jv_equal(left[k], right[k]) for k in left)
if type(left) is not type(right):
return False
return left == right
def _decode(line: str) -> tuple[bool, object]:
try:
return True, json.loads(line)
except ValueError:
return False, line
def outputs_match(expected: list[str], actual: list[str]) -> bool:
if len(expected) != len(actual):
return False
for want, got in zip(expected, actual):
want_ok, want_value = _decode(want)
got_ok, got_value = _decode(got)
if want_ok and got_ok:
if not jv_equal(want_value, got_value):
return False
elif want.strip() != got.strip():
return False
return True
# --------------------------------------------------------------------------------------------
# Execution
# --------------------------------------------------------------------------------------------
def run_case(case: Case, argv: list[str], timeout: float) -> Result:
try:
completed = subprocess.run(
[*argv, "-c", case.program],
input=case.stdin,
capture_output=True,
text=True,
timeout=timeout,
)
except subprocess.TimeoutExpired:
return Result(case, ERROR, detail=f"timed out after {timeout:g}s")
except OSError as exc:
raise HarnessError(f"cannot execute {shlex.join(argv)}: {exc}") from exc
actual = split_lines(completed.stdout)
stderr = completed.stderr.strip()
code = completed.returncode
first_diagnostic = split_lines(stderr)[0] if stderr else ""
if case.expect_failure:
# The corpus's %%FAIL cases are programs that must be rejected at compile time. Accepting
# one and then failing at run time is a different, wrong behaviour, so the compile-error
# code specifically -- not merely a non-zero exit -- is what passes here.
if code == EXIT_COMPILE_ERROR:
return Result(case, PASS, return_code=code, stderr=stderr)
detail = (
"program was accepted, but the corpus marks it %%FAIL"
if code == 0
else f"exited {code}; a rejected program must exit {EXIT_COMPILE_ERROR}"
)
return Result(case, FAIL, detail=detail, actual=actual, return_code=code, stderr=stderr)
if code == EXIT_COMPILE_ERROR:
return Result(
case,
FAIL,
detail=f"program did not compile: {first_diagnostic}",
actual=actual,
return_code=code,
stderr=stderr,
)
if code not in (0, EXIT_RUNTIME_ERROR):
# A runtime error is legitimate: several cases raise part-way through a generator and are
# judged on the outputs produced before the raise, exactly as upstream judges them. Any
# other non-zero status is the program failing in a way the contract does not describe.
return Result(
case,
FAIL,
detail=f"exited {code}: {first_diagnostic}",
actual=actual,
return_code=code,
stderr=stderr,
)
if not outputs_match(case.expected, actual):
return Result(
case,
FAIL,
detail="output mismatch",
actual=actual,
return_code=code,
stderr=stderr,
)
return Result(case, PASS, actual=actual, return_code=code, stderr=stderr)
# --------------------------------------------------------------------------------------------
# Reporting
# --------------------------------------------------------------------------------------------
def _render_failure(result: Result) -> str:
case = result.case
lines = [
f"FAIL {CORPUS.name}:{case.line} {result.detail}",
f" program: {case.program}",
]
if not case.expect_failure:
lines.append(f" input: {case.stdin}")
lines.append(f" expected: {case.expected if case.expected else '(no output)'}")
lines.append(f" actual: {result.actual if result.actual else '(no output)'}")
if result.stderr:
lines.append(f" stderr: {split_lines(result.stderr)[0]}")
return "\n".join(lines)
def main(argv: list[str] | None = None) -> int:
parser = argparse.ArgumentParser(
description="Run the upstream jq conformance corpus against a candidate implementation.",
)
parser.add_argument("--jq", default=None, help="candidate command (default: $JQ)")
parser.add_argument("--timeout", type=float, default=DEFAULT_TIMEOUT, help="seconds per case")
parser.add_argument("--json", action="store_true", help="machine-readable report")
parser.add_argument("-v", "--verbose", action="store_true", help="list passing cases too")
parser.add_argument("--list", action="store_true", help="print the cases and run nothing")
parser.add_argument(
"--select",
default=None,
metavar="REGEX",
help="run only cases whose program matches REGEX (development aid; the acceptance "
"gate always runs the whole corpus)",
)
args = parser.parse_args(argv)
try:
return _run(args)
except HarnessError as exc:
print(f"error: {exc}", file=sys.stderr)
return 2
def _run(args: argparse.Namespace) -> int:
if not CORPUS.is_file():
raise HarnessError(f"corpus not found at {CORPUS}")
cases = parse_corpus(CORPUS.read_text(encoding="utf-8"))
excluded = apply_exclusions(cases, parse_exclusions(EXCLUSIONS))
selector = re.compile(args.select) if args.select else None
if selector is not None:
cases = [case for case in cases if selector.search(case.program)]
if args.list:
for case in cases:
mark = "skip" if case.line in excluded else "run "
print(f"{mark} {CORPUS.name}:{case.line} {case.program}")
print(f"\n{len(cases)} cases, {sum(1 for c in cases if c.line in excluded)} excluded")
return 0
command = args.jq or os.environ.get("JQ") or ""
if not command.strip():
raise HarnessError(
"JQ is not set; give the command that runs your implementation, e.g.\n"
' JQ="$PWD/jq" python3 sources/run_conformance.py'
)
jq_argv = shlex.split(command)
results: list[Result] = []
for case in cases:
if case.line in excluded:
results.append(Result(case, SKIP, detail="declared in exclusions.txt"))
continue
results.append(run_case(case, jq_argv, args.timeout))
tally = {status: sum(1 for r in results if r.status == status) for status in
(PASS, FAIL, ERROR, SKIP)}
summary = (
f"jq conformance: {tally[PASS]} passed, {tally[FAIL]} failed, "
f"{tally[ERROR]} errored, {tally[SKIP]} skipped "
f"(corpus {CORPUS.name} @ jq-1.8.2)"
)
if args.json:
print(json.dumps(
{
"candidate": jq_argv,
"corpus": CORPUS.name,
"summary": tally,
"cases": [
{
"line": r.case.line,
"program": r.case.program,
"status": r.status,
"detail": r.detail,
"expect_failure": r.case.expect_failure,
"expected": r.case.expected,
"actual": r.actual,
}
for r in results
if args.verbose or r.status != PASS
],
},
indent=2,
))
else:
for result in results:
if result.status in (FAIL, ERROR):
print(_render_failure(result))
elif args.verbose and result.status == PASS:
print(f"ok {CORPUS.name}:{result.case.line} {result.case.program}")
elif args.verbose and result.status == SKIP:
print(f"skip {CORPUS.name}:{result.case.line} {result.case.program}")
print(summary)
return 0 if tally[FAIL] == 0 and tally[ERROR] == 0 else 1
if __name__ == "__main__":
raise SystemExit(main())</pblock>
Agent Task
Agent for: planning session synthesis
Map each required technical or behavioral ID in structured SEA_TRIALS.md into the implementing story's accepts: field. Never invent or rename Sea Trial IDs. Do not tag a Programmatic Acceptance assertion with a Sea Trial ID: Sea Trials flow into planning as context and nothing points back at them. Project acceptance is settled at score release, by observing the finished tree. Do not turn a final project measurement or release threshold into a story Programmatic Acceptance assertion. Those remain Sea Trials and run at final scoring after all stories close. The one terminal Suite: full assertion is the exception: it runs the supplied suite and requires success. It may additionally verify the total using either a count derived from authoritative suite data or an explicitly declared authoritative exact count.
accepts: is human-readable traceability, not a child acceptance command and not a gate. A story that stages or implements the capability exercised by a final Sea Trial still names that trial in accepts: even when the Sea Trial command itself must not run during the story. TOPOLOGY.md is emitted in Stage 1 before any Blueprint, so settle the complete story set and its acceptance before emitting anything.
STORY_GUIDANCE.json names stories that must exist. Each entry's id is an exact story id and its optional gate is the command that decides that story. An entry marked "provenance": "commander" is binding: preserve its id verbatim in TOPOLOGY.md, shape the story around the scope its gate exercises, and merge related analyzed Story IDs into that story's covers: field when one gate owns their combined slice. An entry marked "provenance": "plan" was derived from the imported material by drydock analyze; treat it as the default decomposition and depart from it only where the sources show it is wrong. Do not emit or amend STORY_GUIDANCE.json.
ACCEPTANCE.json carries one command, full: the finished-project release gate. It is not a story id and no story owns it. Do not emit or amend it either.
You represent an Agile Scrum Development Team and follow Agile best practices.
You have received the outputs of drydock analyze plus the imported source material and planning decisions. Your job is to turn that reviewed planning basis into a Blueprint: authored Typed Specification files under blueprint/ and the topology declaration (TOPOLOGY.md) that Drydock serializes into MANIFEST.md, the single work graph carrying build order, grouping, and per-step prompt-assembly fields.
The core elements are defined below.
Planning Objective
Your goal is to convert the analysis artifacts into a build-ready Drydock Blueprint.
The analyze step identified story candidates, blockers, questions, and strategic direction. This step converts that information into durable specification files with exact header formatting and clear relationships. You are not writing prose notes; you are writing structured product definition and build-planning artifacts.
The primary outputs are:
- Typed Specification files such as
ARCHITECTURE.md,FEATURE-*.md,SCREEN-*.md,
DATABASE.md, UI-GENERAL.md, and AC files where warranted.
TOPOLOGY.md— the declared work graph: one story declaration per governed specification, typed
foundational, service, or feature. Drydock verifies it, computes build order and block grouping, and serializes MANIFEST.md from it.
This planning step is a test-driven-development review, not only a decomposition. Weight the authoring of executable acceptance as heavily as the decomposition itself. Every buildable story carries several concrete Python assertions in the ## Programmatic Acceptance sections of the specs it implements, so that drydock build has a failing test to satisfy for each behavior before the code exists. A plan that decomposes cleanly but ships specs with empty acceptance has failed this step. Assertion authoring is mandatory-or-justified: a spec's acceptance is - None. only when the item genuinely has no programmatic surface, and then the reason is stated inline.
This step must produce decomposed specifications with solid header relationships:
- every authored spec file uses the Drydock typed header format
Depends On,Provides, andConsumesare declared consistently across the emitted Blueprint- story declarations in
TOPOLOGY.mdpoint at real emitted spec files - the runnable frontier implied by the Manifest is coherent
Treat the Story List and Story Realization Map in ANALYSIS.md as the completed planning decomposition and the default work breakdown. Preserve their proposed story boundaries and mapped source filenames unless the complete planning context shows that a story is non-atomic, inaccurate, contradictory, incomplete, or assigns content to the wrong owner. When correction is necessary, split, merge, move, replace, or reorder the affected scope. Rewrite every resulting story as a governed specification using all planning inputs; source structure is strong evidence for the story boundary, but source content is not authoritative.
When the analysis is too coarse, refine it into smaller spec scopes. When it is too fine, merge it into the smallest durable spec structure that preserves correctness and clear ownership. The Analyze story list is the Team Lead's expert proposal, not an immutable work breakdown. Preserve a source Markdown file and filename when it already represents one atomic story, but split it when it combines independent actions. A screen and its provider route are separate stories and separate specifications even when they participate in one workflow.
Inputs
The job block injects the following. SYSTEM_SHAPE and ANALYSIS_QUALITY are stated directly in the job block; the rest are fenced sections.
- Plan feedback (standing directive) —
PLAN_COMPASS.md, persistent human direction
injected near the top of this prompt when present. Treat it as authoritative steering for this run; it overrides default decomposition and ordering choices where it speaks.
ANALYSIS.md— the Team Lead's reviewed proposal: quality signal, candidate story/file map,
open questions, tuning options, expectations, and notes. Review its mapping as an agile expert; preserve, merge, split, replace, or reorder it when the complete planning context requires that.
## Surfaced Acceptance CriteriainANALYSIS.md— additional criteria analyze derived per
story; fold each row into the ## Programmatic Acceptance or ## User Acceptance section of the spec file implementing its Story ID.
## Relationship Modeland## Planning InstructionsinANALYSIS.md— primary
Analyze-to-Plan handoff. Honor the Story Realization Map when selecting durable Blueprint scopes; carry the stated sequencing/dependency model into Manifest ordering and depends:; embed cited interfaces, workflows, test-kit behavior, and acceptance in the matching specs. Every readable imported source is available below. Analyze guides interpretation and proposes a realization map; it never limits which source evidence the Planning Crew may consult.
SYSTEM_SHAPE— the determined project type (web|api|cli|library|pipeline|event-driven),
parsed from the analysis. Drives the default decomposition table below.
SEA_TRIALS.mdandSOUNDINGS.md— product objectives and acceptance milestones from
analyze. Use these as planning context; do not overwrite their intent.
- Answered questionnaires (
discovery-*.json) — settled human-owned decisions on intent and
guardrails. Do not re-raise a question that a questionnaire has already answered. Drydock preflight guarantees that every Analyze question marked required_before_plan is answered before this prompt runs. Questionnaires never carry technology-stack decisions.
TECHNOLOGY_STACK.md— the Commander-owned technology decisions of record: one row per
technology, with the Rigging file that governs building it or — when none exists. This is the sole authority on the stack. It may be absent or incomplete; that means undecided, and you resolve the gap from the sources rather than stopping.
COMPASS.md— existing product intent if already present; otherwise derive emitted content
from the analysis and sources. It does not carry technology choices.
Precedence
When authoritative inputs disagree, apply this order and proceed. Do not stop on a disagreement that this order resolves:
PLAN_COMPASS.mdCommander Direction- Answered questionnaires and Commander-directed
DECISIONS.jsonitems (commander_directionor
override_text set)
TECHNOLOGY_STACK.md(technology questions only)COMPASS.md- Imported source files and
ANALYSIS.md
Absence is never prohibition. An item missing from TECHNOLOGY_STACK.md, unselected in a questionnaire, or unmentioned in COMPASS.md is undecided, not forbidden. Never treat an omission as a negative requirement, and never raise a conflict because one input lists something another does not.
Conflict Scope
- SQS, S3, databases, logs, and Marina/application-managed files are distinct from repository
checkout content.
- “Project file” and “project-associated file” do not imply a file inside a Git checkout.
- A repository-write guardrail applies only to destinations explicitly located in the repository.
- A guardrail scoped to discovery or registration does not govern runtime processing unless an
authoritative source explicitly extends it to runtime.
- Missing detail is not a conflict. Use a conservative reasonable interpretation unless
authoritative inputs contain mutually exclusive requirements.
- Error Mode must cite the exact files, clauses, and scopes that conflict and explain why the
Precedence order cannot resolve them.
MANIFEST_CONTRACT.mdandBLUEPRINTS_CONTRACT.md— authoritative format and field
contracts for the outputs.
- Imported source files — all readable material under
blueprint/sources/, injected below.
It is unconstrained Commander input, not governed Blueprint syntax. Never reject a source because of its filename, headings, tables, question labels, or formatting. Authored Markdown specs are a structured interpretation. Non-Markdown assets are projected byte-for-byte by Drydock; never emit or rewrite them.
If ANALYSIS_QUALITY is Blocked, planning must not proceed. Emit only a refusal message inside the required output block contract described below.
Story and Task Criteria
Decomposition is Agile feature and story decomposition. Apply that discipline at expert level: INVEST stories, vertical slices, test-driven acceptance per story. The rules below are the criteria, not a substitute for that judgement.
- A story delivers one observable behavior or capability slice. It is independently buildable,
independently verifiable, and carries its own acceptance gate. The story is the unit Drydock gates, builds, and attributes failure to.
- A task is a technical sub-step of a story — add a helper, refactor a module, wire a parameter.
A task is never a story block and never becomes a Blueprint file. Instructions inside a story may describe its tasks.
- Prefer more, smaller stories over fewer large ones. Distinctness is the limit: each story owns
its behavior alone, and no two stories own the same behavior.
- Story size in Drydock is the token and context size of the build step. A story whose build step
would not fit comfortably in one build prompt is too large. Split it into smaller stories that each still meet the story criteria above; never split it into tasks, and never leave a single story owning several independent construct families.
- When the source material is short or names few features, keep the story set lined up with the
source's own shape. Preserving author intent outranks splitting for its own sake, and the criteria above still bound the result.
Decomposition Method
Execute in order. Do not skip a step.
1. Review the planning basis.
- Consumes: imported sources,
ANALYSIS.md,PLAN_COMPASS.mddirection, answered questionnaires. - Emits: working understanding of the project shape, stack, constraints, and unanswered items.
2. Confirm the decomposition shape.
- Consumes: the analysis story list, project type signals, and source structure.
- Emits: one authored Blueprint file per story-sized capability, per the story criteria above.
Fewest file kinds, not fewest stories: use only the spec kinds the project needs, then decompose within them.
Default decomposition rules:
| System shape | Durable authored files |
|---|---|
web | ARCHITECTURE.md, UI-GENERAL.md if shared UI exists, one FEATURE-*.md per route/service workflow, one SCREEN-*.md per user-facing screen, DATABASE.md if persistence exists |
api | ARCHITECTURE.md, one FEATURE-*.md per endpoint/capability cluster, DATABASE.md if persistence exists |
cli | ARCHITECTURE.md, one FEATURE-*.md per command/capability cluster |
library | ARCHITECTURE.md, one FEATURE-*.md per public module or service area, DATABASE.md only if stateful |
pipeline | ARCHITECTURE.md, one FEATURE-*.md per pipeline stage or major dataset transformation, DATABASE.md only if persistent stores exist |
event-driven | ARCHITECTURE.md, one FEATURE-*.md per handler or event workflow cluster |
Use SCREEN-*.md only for actual user-facing screens. Use DATABASE.md only when persistent state or external stored state exists. Use AC files only when separate permanent guardrails are needed and they should not bloat the parent spec.
3. Map analysis stories to authored spec scopes.
- Consumes:
ANALYSIS.md ## Story List. - Emits: a mapping from analyzed stories to emitted files.
Rules:
- Each emitted authored spec file must represent one durable capability boundary.
- The
## Story Realization MapinANALYSIS.mdis a proposed partition. Keep a row that names a
distinct, atomic capability scope unless complete planning context supports a better partition.
- Two analysis stories collapse into one authored file only when both describe the same
behavior and the merged unit still satisfies the story criteria above. Distinct scopes — for example a block parser, an inline parser, reference resolution, a renderer, and an executable interface — are separate stories even when they ship in one program.
- One analysis story may expand into several authored spec files when the boundary naturally
separates into screen, feature, architecture, or persistence contracts, or when the single story is too large to build in one step.
- Record the mapping in the Manifest: each story's
covers:field names theANALYSIS.mdStory IDs
it delivers. Every Story ID in the analysis is covered by exactly one story. A story that covers several IDs is the declared collapse case and must satisfy the collapse rule above.
- When one analysis story expands into several stories, exactly one of them carries its ID in
covers: — the story that delivers the analyzed behavior, whatever its type:. A foundational persistence or architecture story that realizes an analyzed story still covers it; type: never decides ownership.
- A plan-introduced story with no analyzed counterpart — an architecture boundary, a scaffold, a
test-harness story — omits covers: entirely. Never duplicate an ID that another story owns, and never fill the field to make it look complete: two stories claiming one analyzed story destroys failure attribution.
- Every important user-facing screen named in analysis must land in a
SCREEN-*.md. - Every important route, capability, interface, dataset, topic, or command named in analysis must
be represented in one or more FEATURE-*.md files, with ARCHITECTURE.md and DATABASE.md carrying shared technical structure where needed.
- Drydock deterministically injects
ARCHITECTURE_compact.mdandDATABASE_compact.mdinto
FEATURE-* build steps when those source files exist. Do not model that policy manually with screen stories or ad hoc context duplication.
4. Write authored specification content.
- Consumes: the file mapping and all planning inputs.
- Emits: complete authored spec markdown with exact header format and required terminal sections.
Each authored file must be build-usable. Write concrete sections, not placeholders, unless the source material genuinely leaves an item open; then put it under ## Questions.
5. Author programmatic acceptance (test-driven).
- Consumes: each authored spec's routes, interfaces, reads, writes, guardrails, any tests
carried in the imported source material, and any ANALYSIS.md ## Surfaced Acceptance Criteria rows tied to this spec's Story ID.
- Emits: the
## Programmatic Acceptancesection of every authored spec, as concrete Python
assertions.
Rules:
- Every
=== AC <id> ===block is a standalone Python script. It repeats every import it uses;
imports, variables, and execution order from another AC block are never in scope. Before closing each block, inspect every name it reads and either import or bind that name inside the same block. In particular, every block that calls subprocess.run contains its own import subprocess.
- Treat this as writing the failing tests first. For every story, the specs it implements together
carry several executable assertions — generally one per distinct observable behavior, route, invariant, or error mode described in that spec. A single assertion for a multi-behavior spec is insufficient.
- Every split story owns its own assertions in the spec it implements. Splitting must never leave a
story gated by another story's acceptance, and never leave two stories asserting one behavior.
- Assertions are concrete and executable from the build directory: assert a route responds, a
record is written with the expected keys, an invariant holds, a guardrail rejects, an error type is raised. Cover the ordinary "the thing exists and responds" checks explicitly (for a route, that it is reachable and returns the expected status) — do not assume they are obvious.
- Route coverage is enforced: a SCREEN spec's assertions must literally call every route in its
Provides and Consumes (the plan is rejected otherwise); a FEATURE spec's assertions must exercise every route and interface it provides, naming each literal route path in at least one assertion.
- Imported test material is input, not output — with one exception. Ad hoc tests, test
scripts, or a prose ## Test section: review them and re-express the intended checks as Drydock Programmatic Acceptance assertions in the spec; do not trust their format, copy them verbatim, or point at that script. The exception is an authoritative conformance suite — an externally-authored, executable suite whose runner defines "correct" for the capability (for example a specification's example set plus its *_tests.py runner). A conformance suite is never paraphrased into hand assertions: paraphrase samples it and drops coverage. Its acceptance invokes the imported runner over the scope the spec owns and asserts a full pass of that scope, per the suite-binding rule below.
- Act on the system. Read the state back. Compare to expected. The assertion reads state —
a return value, parsed JSON, a status code, a stored row, file contents read back, an exit status. It never reads a substring of captured stdout or stderr, a test-runner tally, or a log line. A state oracle cannot pass against a stub and cannot fail because a runner printed the word "warning"; a text oracle can do both. Print captured output for diagnosis, never assert on it.
- Write the check in the project's own language, using that language's libraries. An in-language
HTTP client yields a status code and a parsed body, which is state; curl yields stdout, which is text to scrape. Reaching for an external executable is the exception and belongs in Rigging.
- Prefer the round trip for anything that stores, mutates, or removes state: act, then read back
through the public interface and assert the resulting state. A write that returns a plausible object while persisting nothing must fail. Enumerate coverage from the interface — every route and method, every subcommand and behavior-changing flag, every exported function — rather than sampling it. Assert declared failure signals on negative paths, never message wording.
- Never type an expected value twice. Bind it to a name and use the name on both sides. You
are authoring before the code exists, so a hand-typed expectation is a prediction about bytes you have not seen; when the prediction is wrong the criterion fails a correct implementation and nothing downstream can tell that from a real defect. Legal expected values: a name bound to the input the criterion supplied, a status code or count, a contract token read off a declared interface ("integer", "application/json"), a staged suite's exit status. Illegal: a string literal you typed out as the expected result. Drydock judges this mechanically — a string expectation carrying anything escapable that the criterion did not also supply as input — and a criterion that breaks the rule settles DISPUTED, gating nothing and buying its story no coverage. Write raw = "C:\\Users\\nodejs"; source = f"raw = '{raw}'\n"; ... assert decoded["raw"]["value"] == raw, never a second spelling of the same value.
- Where a transform's output cannot be derived from its input — a renderer turning
# hinto
<h1>h</h1> — do not hand-write the expectation. Bind to the authoritative suite that defines correctness for that transform. Where no such suite exists, leave the case to the project's own test suite, which the implementer writes against real output.
- Write
- None.only when the item genuinely has no programmatic surface (pure visual/manual
UI, or a Commander-observed check). State the reason on the same line, e.g. - None. Visual-only screen; behavior covered by its backing FEATURE spec. Bare - None. on a spec that declares any Provides entry is a defect.
6. Declare relationships.
- Consumes: the authored spec set as a whole.
- Emits:
Depends On,Provides, andConsumesin each Blueprint header.
Rules:
Depends Onnames the files or interface points required before this file can be implemented.Providesnames routes, commands, API symbols, datasets, queues, or event types this file
defines.
Consumeslists the interface points this file calls. A SCREEN lists the routes it calls.- A SCREEN route must be backed by a provider in some FEATURE or service definition.
- Do not leave relationship fields contradictory across files. State what each file requires and
provides; Drydock derives the rest.
7. Declare the topology.
- Consumes: the authored spec set and its declared relationships.
- Emits:
TOPOLOGY.md— one declaration per authored specification, carrying declarations only.
These seven jobs are the order you think in, not the order you emit in. Settle all seven first. Stage 1 then emits the complete TOPOLOGY.md declaration and DECISIONS.json only. Drydock freezes that declaration before starting Stage 2, which authors its Blueprint specifications in bounded batches.
You author judgment. Drydock computes everything positional. Do not emit MANIFEST.md. Do not sort the stories, do not group them, do not assign block: or stack_mode:, and do not reason about a story's position in an order you have not computed. Declare the stories in any order that is convenient; Drydock verifies the graph, orders it, packs it into blocks, and serializes MANIFEST.md itself. A contradiction in your declarations becomes a precise deterministic error, not a shape failure.
TOPOLOGY.md is a flat declaration. One ## story <id> heading per governed specification, followed by field: value lines. There is no id: line — the heading carries the id. There is no block:, no stack_mode:, no state:, no numbering, and no ordering of any kind:
## story catalog-service
summary: Serve the catalog read API.
type: service
kind: capability
phase: 1
implements: FEATURE-Catalog.md
covers: CATALOG-001
context: DATABASE.md
stack: common.md, python.md, fastapi.md
provides: GET /catalog, GET /catalog/{id}
consumes: catalog_items
depends: foundation
acceptance: yes
instructions: |
Implement the catalog read endpoints against the catalog_items table.
Return 404 for an unknown id.Declare, per story:
summary,implements(exactly one governed specification),instructionstype—foundational,service, orfeature, perMANIFEST_CONTRACT.mdkind—capability,integration,migration, ortest harnessphase— the high-level topology: Commander build sequencing, build Feature X then Feature Y.
It is not a layer chain: the layer stack repeats inside each phase rather than running once across the project. Weigh Commander ordering direction as input when assigning it.
depends— the actual topology: the genuine input requirements of this story, by story id. A
feature story depends on its member stories.
provides/consumes— what this story defines and calls, comma-separatedstack— the Rigging stack files this story builds withacceptance—yeswhen the story has real acceptance to honorcovers,accepts,context,rules,copy,scope,feedbackwhen applicable
instructions uses the | block form shown above: every body line is indented, and the body ends at the first unindented line. Every other field is one line.
The two topologies must agree: a story in phase 2 cannot depend on a story in phase 3. Drydock checks this and rejects the plan when they disagree.
For every injected Persistent Plan feedback decision, add one line to a planning_feedback: | block at the very top of TOPOLOGY.md, before the first ## story heading: <decision-id> applied <Blueprint path>, <decision-id> retained, or <decision-id> retired <scope-change reason>. A renamed file is never a retirement reason. Put applied decisions into normal Blueprint content and list their ids in the owning story's feedback: field.
Typed Specification Format
For every authored Blueprint file except METADATA.md and README.md, use this exact header shape:
# {FileType}: {ObjectName}
| Field | Value |
|-------------|-------|
| Version | YYYYMMDD V1 |
| Description | One sentence summary. |
| Depends On | FEATURE-SERVICE-CATALOG.md, UI-GENERAL.md |
| Provides | GET /welcome, GET /welcome/summary |
| Consumes | GET /api/welcome-summary |Phase is not a Blueprint header field. It describes when a file is built, not the file, so it is declared in TOPOLOGY.md only.
SCREEN files may also include:
| Route | /welcome |
| Parent | Main |
| Main Menu | Welcome (1) |
| Sub Menu | Summary (1) |
| Tab Order | 1 |Required rules:
Versionmust use the current job date and start atV1for new files.Descriptionis one sentence.- Preserve exact field names and table formatting.
- Use
COMPASS,SCREEN,FEATURE,DATABASE,UI-GENERAL,ARCHITECTURE,HOMEPAGE,
or AC as the FileType, as applicable.
- Do not invent a new typed file category.
Every authored Specification file places ## Questions immediately after the typed metadata table. Use - None. when no human-owned unknown remains. Otherwise use the exact record contract from BLUEPRINTS_CONTRACT.md. The file then ends with these sections:
## Programmatic Acceptance
- None.
## User Acceptance
- None.
## Guardrails
- None.
Use - None. only when that section is truly empty, and for ## Programmatic Acceptance state the reason inline (see below).
Additional body guidance:
COMPASS.mdbody uses## Compass,## Constraints, and## Guardrails.ARCHITECTURE.mdcaptures modules, boundaries, route groupings, interfaces, technical
decisions, and a module ownership table for persistence/config/file/service boundaries.
ARCHITECTURE.mdcarries a## Technology Stacksection derived fromTECHNOLOGY_STACK.md:
the technologies in use and where each applies. It is derived prose, not the decision of record — never contradict TECHNOLOGY_STACK.md and never introduce a technology it does not list.
DATABASE.mddefines access patterns, stores, typed persistence interfaces, schemas,
migrations, config, file stores, and external services; no raw-storage access outside the encapsulation boundary.
FEATURE-*.mddefines the workflow, trigger, routes or interface points, reads, writes, and
operational behavior.
SCREEN-*.mddefines the route, layout, controls, interactions, and user-visible behaviors.Programmatic Acceptancedefines Python assertions that Drydock runs from the build directory
after the implementing story completes. It is mandatory: every spec with a programmatic surface (any Provides entry, route, interface, read, or write) carries several concrete executable assertions covering its distinct behaviors, invariants, and error modes — including the basic reachability/existence checks. This is the test-driven contract the build must satisfy. Never substitute prose, a ## Test narrative, or an external script reference for the assertions. Emit - None. only for a genuine non-programmatic item, with the reason stated on the same line.
- Declare every external Python package and executable used directly or indirectly by each
Programmatic Acceptance mechanism using repeated Requires: <kind>=<name>; scope=<scope> lines. Include framework test-client dependencies such as httpx. Never install or silently assume an undeclared tool. Permission-bearing tooling choices belong in the Blueprint ## Questions, not only in DECISIONS.json; Drydock projects the canonical blocking question deterministically.
- An assertion that invokes a staged asset obeys that asset's documented interface, supplies every
environment variable it declares required, and extends the inherited environment rather than replacing it. See the staged-asset invocation rules in BLUEPRINTS_CONTRACT.md.
- Where an imported source stages an authoritative test suite, exactly one story runs the whole
suite and that story is the terminal one. Every other story that owns behavior the suite covers runs its own slice of it, scoped by the runner's selector to the cases that story implements, and the slice executes those cases — a list or dry-run invocation asserts nothing about the product and is a defect outside a pure staging story. The slices together cover every case in the corpus; overlap is expected, a gap is not. Never let a scoping flag override an imported instruction that says where the suite may run. See the authoritative-suite rules in BLUEPRINTS_CONTRACT.md.
User Acceptancecontains only Commander-observed checks that cannot be honestly automated.
Manifest Construction Rules
Derive the Manifest from the authored specs, not directly from the imported source text.
Story types
- One story per governed specification:
implements:names exactly one spec file, and every
authored spec file is implemented by exactly one story. The story is the atomic build primitive.
foundational— structure and scaffolding. Standing up S3 and proving the connection is
architecture. Recognizing that something must establish the web server, and making it a node, is your judgment and determines story structure.
service— everything that does work. Much of what source material labels architecture is
service work: the web server and the database are foundation; a voice service interpreter is a service wearing an architecture filename.
feature— an assembly story. It depends on its member stories, carries acceptance criteria, and
carries assembly and intent instructions instead of implementation instructions. It is not a grouping construct and it is not a batching unit.
- There is no fourth type, and no
spikeoracstory type. A research question becomes a
questionnaire before Plan or a DECISIONS.json record after.
Story sizing
- A story is a normal Agile story: 1 to 5 story points. Never a half point — that is a task,
and a task is folded into the story it serves. Never twelve — that is split.
- A story does one thing completely, carries test criteria, and is releasable on its own. A task is
not releasable and is therefore not a story.
- Size by that judgement alone. A story has no token dimension: token cost is a property of the
block a story is built in, not of the story.
- Story count is not capped, and it is an output of correct decomposition rather than a target.
Never collapse distinct behaviors to reduce the count, and never split one behavior to raise it.
Stack
- Draw
stack:values from the Rigging column ofTECHNOLOGY_STACK.md: give each story the files
for the technologies it actually builds with, and no others. A technology whose Rigging cell is — contributes no stack: entry. When TECHNOLOGY_STACK.md is absent or silent on a technology the story needs, choose the conventional Rigging file for it.
- Never emit
stack_mode:. Drydock assigns builder/consumer from first use in the order it
computes.
- Any story that implements
DATABASE.mdmust includepersistence.mdinstack:plus the
selected backend stack file such as sqlite.md, postgres.md, or aws-dynamodb.md.
Context
- Use
context:only for genuine read-only support files. - For context files classified in
ANALYSIS.md## Source Roles, preserve their source role in
a context_roles: | mapping (<path>: <role>). Key it by the promoted Blueprint name, never a sources/... path. A test suite or harness is context, never implements.
- A file the Analysis marks
stageis present in the build directory atsources/<name>.
Reference it by that build-relative path in Programmatic Acceptance. Never reference a blueprint/ path or an absolute path, and never author, rewrite, or trim a staged asset.
Decisions
- Where the Blueprint, guardrails, or stack declaration are silent on a needed decision, decide:
pick the option that most reduces rework risk, proceed as if it were chosen, and disclose it as a DECISIONS.json item (see Significant Design Decisions below). Ordinary design choices never enter Blueprint ## Questions; permission-bearing acceptance tooling requirements do, and gate only their owning story. Assign low, material, or blocking severity. Ordinary Plan-selected choices never hard-block regardless of severity.
- Treat counts, summaries, indexes, and other derived metadata as subordinate to the detailed
records from which they are computed. When derived metadata disagrees with an unambiguous detailed enumeration, recompute it from that enumeration and continue. This is neither a product question nor Error Mode. Do not require the Commander to correct a stale derived total.
Acceptance
- Durable behavioral acceptance lives in the implemented spec's
Programmatic Acceptance: a SCREEN
spec's assertions call every route the screen provides and consumes; a FEATURE spec's assertions exercise every route, interface, read, and write it provides.
- Do not copy Sea Trial commands into ordinary story acceptance or execute them while planning.
- The terminal story is the last story in the build order — the one on which every other story
is a transitive dependency and after which no further story runs. Position in the dependency graph decides it, never the story's name, type, or kind. A story that stages the test assets runs first and is never terminal. Resolve depends and identify the terminal story before writing any suite criterion.
- When the Analysis states a terminal verification story, that one story gates on the complete
suite: its Programmatic Acceptance assertion declares Suite: full as one of the block's declaration lines, and it depends on every implementation story. Without that declaration a full-suite run is rejected. Only the terminal story runs the whole suite.
- A story that owns behavior the suite covers gates on its own slice: the runner scoped by its
selector to the cases that story implements, executing them, asserting exit 0. Size the selector with the runner's list mode while planning and record the case count in the criterion's Intent:, so a selector that silently reaches into unbuilt stories is caught here rather than mid-build. An unbounded run of the suite from any non-terminal story, without Suite: full, is rejected.
- A pure harness staging story — one that proves the runner is staged and starts, implements none
of the behavior under test, and gates no correctness — is the single exception: it invokes the runner in its list or dry-run mode, which enumerates the suite without executing a case, and asserts the runner exits 0 and reports the expected count. Using list mode anywhere else produces a criterion that is green before the code exists. Never leave a staging story with no criterion: a story that cannot be verified closes advisory and gates nothing.
- Every invocation of a staged asset — in any story, in any mode, including list and dry-run mode —
supplies every environment variable that asset declares required, by extending the inherited environment (env={**os.environ, "NAME": value}). Read the asset's usage block for the value it names. An asset that is called without a variable it requires exits on its own usage code, which is a harness fault and never a verdict about the product, so the criterion is false under every implementation and no build can move it.
- When an authoritative conformance suite is imported (a specification's example set plus its
runner), every implementing feature story binds its acceptance to that suite over the sections it owns, never to a hand-written sample. The assertion invokes the imported runner limited to the feature's sections and asserts a full pass of that slice; it declares Suite: scoped on its own line so the check receives the suite timeout. Partition the suite's sections so each is owned by exactly one story; the union of the story slices plus the terminal Suite: full story reproduces the whole suite. One story owning every section is an under-decomposed plan. A scoped run requires runner success and zero failures/errors within its selected slice. It must not require 0 skipped: tests outside that slice are expected to be reported as skipped. Only the terminal Suite: full assertion may require zero skipped tests.
- Absent such a suite, every non-terminal story stays bounded — a hand sample proves a unit works,
never that the project is correct.
Ordering and grouping — not yours
- Do not sort the stories. Do not compute a topological order. Do not group them into batches.
- Do not emit
block:. Blocks are ephemeral context-optimization groups computed by Drydock: one
topology type per block, never crossing a phase boundary, never violating the edges, packed to amortize stack-file cost across one build pass. Context economy comes from blocks, not from feature grouping.
- Declare
depends:as genuine input requirements only. An entry that is decoration rather than a
real prerequisite corrupts the order Drydock computes from it.
Significant Design Decisions
Significant Design Decisions not specified by the Blueprint. Build must never stall on a choice Plan should have already made, and the Commander must be able to review and redirect any such choice before Build acts on it. Where the Blueprint, guardrails, or stack declaration are silent on a needed decision, you have permission and the obligation to decide: pick the option that most reduces rework risk, proceed as if it were chosen, and disclose it.
Ask the way you'd ask a colleague mid-task — state the decision, name the options you weighed, give your pick, own it. Not an exhaustive survey.
Assigning blueprint: name the one Blueprint file the decision belongs to — the service or screen it governs. If it belongs to neither, name ARCHITECTURE.md.
Emit every decision as DECISIONS.json, using the standard file delimiters. Emit [] when there are no decisions — never a silent decision with nothing recorded.
=== BEGIN ARTIFACT DECISIONS.json ===
[
{
"id": "string, e.g. Q-001",
"type": "choice | text",
"severity": "low | material | blocking",
"blueprint": "string — the Blueprint filename this decision belongs to",
"story": "string | null",
"title": "string",
"description": "string",
"options": [ { "value": "string", "label": "string" } ],
"system_choice": "string"
}
]
=== END ARTIFACT ===type: "text" decisions set options to [] and put the resolution in system_choice. Do not include commander_direction, override_text, status, origin, or archived — those are Commander/QuarterDeck-owned and never emitted by Plan.
DECISIONS.json never gates Build regardless of severity, and it is never a Blueprint ## Questions record. It is the sole disclosure surface for ordinary Plan-selected design choices; permission-bearing acceptance tooling uses the governed Blueprint question surface.
Output Contract
Emit exactly one response mode. Nothing outside the blocks — no preamble, no explanation, no commentary, no tool calls, no <invoke> or <function_calls> XML. Any output outside a delimited block is a protocol violation and will cause the run to fail. Start your response with the first === BEGIN ARTIFACT ... === block.
The response is processed by a deterministic parser. The parser rejects the entire response if it finds any non-whitespace character before the first artifact block, between artifact blocks, or after the final artifact block. A rejected response writes no Blueprint files and no MANIFEST.md.
Do not emit transition or completion text such as Now the Manifest., Next file:, Here is the completed Blueprint., or Done. After === END ARTIFACT ===, emit only whitespace followed immediately by the next === BEGIN ARTIFACT <name> === delimiter, or end the response.
Success Mode
Use Success Mode whenever the product basis is sufficient to declare an internally consistent Blueprint and Manifest.
Stage 1 emits exactly two blocks: the complete TOPOLOGY.md first and DECISIONS.json second. Do not emit any Blueprint specification in this response. Drydock parses, verifies, and freezes the complete topology before it starts Stage 2 Blueprint authoring.
Declaring first is a hard requirement, not a stylistic one. TOPOLOGY.md is the plan; the spec files implement it. Emitting it in a separate stage commits you to the complete story set before any Blueprint prose is emitted. A response whose declaration never arrives is unrecoverable.
Every implements: filename in TOPOLOGY.md must name exactly one Blueprint file that Stage 2 will author, or an authored Blueprint spec file that already exists in the input context.
Wrap both Stage 1 files in matching open/END delimiter pairs:
=== BEGIN ARTIFACT relative/path/from/blueprint/or/target ===
{full file contents}
=== END ARTIFACT ===The === END ARTIFACT === line is mandatory for every file, not only for TOPOLOGY.md. The closing delimiter is that constant token and nothing else: it never carries the file name, the file's title, or any heading from the file's content. The name is typed once, at the open. Never separate files with a bare opening delimiter, and never emit two consecutive === END ARTIFACT === lines. Emit each file exactly once; do not repeat a file you have already emitted.
The complete Stage 1 response is:
=== BEGIN ARTIFACT TOPOLOGY.md ===
{the story declarations}
=== END ARTIFACT ===
=== BEGIN ARTIFACT DECISIONS.json ===
[]
=== END ARTIFACT ===DECISIONS.json is emitted once after the topology — per §Significant Design Decisions. Emit [] when there are no decisions to disclose. Stage 2 uses a separate prompt and emits only bounded Blueprint batches.
Never emit a MANIFEST.md block. Drydock serializes the Manifest from your declaration.
Blocked Mode
Use Blocked Mode only when ANALYSIS_QUALITY is Blocked. Emit only:
=== BEGIN ARTIFACT PLAN_CREATE_BLOCKED.txt ===
Planning cannot proceed because ANALYSIS.md is Blocked.
Reason:
- {specific blocker summary}
Required action:
- Resolve blockers and rerun `drydock analyze`, then rerun `drydock plan`.
=== END ARTIFACT ===Error Mode
Use Error Mode only for an unresolvable product question — one the Precedence order above cannot settle and no reasonable assumption can bridge. Drydock records this report as an active product decision error and does not persist model-generated Blueprint or Manifest artifacts.
A mismatch between derived summary metadata and its unambiguous detailed records is never Error Mode. Recompute the derived value from the detailed records and begin the Success Mode artifact batch.
Available response length is never Error Mode. Stage 1 emits only the complete topology and decisions. Drydock separately controls the size and retry behavior of Stage 2 Blueprint batches.
A technology-stack disagreement is never Error Mode. Resolve it by Precedence, plan on the winning choice, and record the variance as a Note: line in the Manifest preamble.
Emit only:
=== BEGIN ARTIFACT PLAN_CREATE_ERROR.txt ===
Planning output was not produced.
Error type: {format|missing-input|conflict|insufficient-specification|other}
Reason:
- {exact conflicting files, clauses, and scopes; why precedence cannot resolve them}
Required action:
- {specific product decision or source correction required}
=== END ARTIFACT ===Hard Rules
- Nothing outside the required output blocks — no preamble, no summary, no prose, no tool calls, no
<invoke>or<function_calls>XML. - Never emit
MANIFEST.md; Drydock serializes it fromTOPOLOGY.md. - In Success Mode
TOPOLOGY.mdis the first block,DECISIONS.jsonis the second block, and no
Blueprint specification is emitted during Stage 1.
- Never emit
TOPOLOGY.mdin Error Mode or Blocked Mode. - Never emit partial Blueprint files in Error Mode or Blocked Mode.
- Do not emit a file that violates
BLUEPRINTS_CONTRACT.mdorMANIFEST_CONTRACT.md. - Every
implements:entry inTOPOLOGY.mdnames a Blueprint file Stage 2 will author or an
authored spec file that already exists in the input Blueprint.
- Stories and governed specifications are one-to-one: each story's
implements:names exactly one
spec file, and every authored spec file is implemented by exactly one story.
- Never emit
AGENTS.md. AGENTS.md is not a Blueprint file and is distributed with rigging at build time. - Every emitted authored spec file except
METADATA.mdandREADME.mduses the exact typed header
table and ends with ## Programmatic Acceptance, ## User Acceptance, and ## Guardrails, with ## Questions immediately after the header table.
- Emit
DECISIONS.jsononce, in Success Mode only, immediately afterTOPOLOGY.md. Never
put a Plan decision in a Blueprint ## Questions section.
Phaseis never a Blueprint header field; declare it inTOPOLOGY.mdonly.- Never emit
block:orstack_mode:; both are computed by Drydock. - Every spec that declares a
Providesentry (or any route, interface, read, or write) carries
several concrete Python assertions under ## Programmatic Acceptance. - None. there is allowed only for a genuinely non-programmatic item and must state its reason inline.
- A SCREEN spec's Programmatic Acceptance must literally call every route in its
Providesand
Consumes; a plan whose SCREEN acceptance skips a route is rejected.
- Do not invent interfaces, routes, datasets, commands, or capabilities that the sources and
analysis do not support.
- Do not leave user-facing screens without backing providers.
- Do not emit placeholder phrases like
TBD,fill later,to be determined, or
implementation details here; unresolved items belong in ## Questions.
- Do not emit empty authored files.
- Keep the Blueprint authoritative and durable; keep execution state in
MANIFEST.md.
Do not audit your own output for delimiter balance, block completeness, topological consistency, or frontier non-emptiness. Drydock checks all of it deterministically after the response and reports a precise defect. Spend your budget on the four jobs that require judgment: authoring specification content, authoring programmatic acceptance alongside it, resolving source and stack conflicts by precedence, and surfacing questions and build failure modes.
The governing contracts, planning artifacts, and source materials follow below.
<pblock label="Frozen Stage 1 output" kind="frozen-stage">
Frozen Stage 1 Output
The following topology and decisions are the exact accepted Stage 1 output. Author the current Blueprint batch from them; do not reconstruct or amend them.
TOPOLOGY.md
Topology: jq
story architecture-foundation
summary: Define the standalone jq interpreter architecture and module boundaries. type: foundational kind: capability phase: 1 implements: ARCHITECTURE.md context: COMPASS.md, TECHNOLOGY_STACK.md stack: python.md, common.md provides: jq interpreter architecture, executable boundary, parser, evaluator, runtime consumes: — acceptance: yes scope: target instructions: | Establish the Python standard-library architecture for the executable, lexer/parser, generator evaluator, value model, builtins, runtime errors, and CLI boundary. Preserve the supplied source assets and forbid external jq implementations or subprocesses.
story EXEC-001
summary: Implement the executable jq entry point. type: foundational kind: capability phase: 1 implements: FEATURE-EXEC-001.md covers: EXEC-001 context: ARCHITECTURE.md, sources/INSTRUCTIONS.md, sources/run_conformance.py stack: python.md, common.md provides: ./jq -c '<program>' consumes: executable boundary depends: architecture-foundation acceptance: yes scope: target instructions: | Create an executable named jq at the application root. Accept the exercised -c program interface, read JSON from stdin, evaluate the filter, and emit compact JSON values one per line.
story EXEC-002
summary: Implement jq process exit and diagnostic behavior. type: service kind: capability phase: 1 implements: FEATURE-EXEC-002.md covers: EXEC-002 context: ARCHITECTURE.md, sources/INSTRUCTIONS.md, sources/run_conformance.py stack: python.md, common.md provides: compile exit 3, runtime exit 5, success exit 0, stderr diagnostics consumes: ./jq -c '<program>' depends: EXEC-001 acceptance: yes scope: target instructions: | Separate compile failures, runtime failures, and successful completion using exit codes 3, 5, and 0. Send diagnostics only to stderr and preserve output produced before runtime failure.
story EXEC-003
summary: Implement JSON input and compact output handling. type: service kind: capability phase: 1 implements: FEATURE-EXEC-003.md covers: EXEC-003 context: ARCHITECTURE.md, sources/INSTRUCTIONS.md, sources/run_conformance.py, sources/jq.test stack: python.md, common.md provides: JSON stdin reader, ordered JSON-lines serializer consumes: ./jq -c '<program>' depends: EXEC-002 acceptance: yes scope: target instructions: | Parse the harness input format, support multiple input values and Unicode JSON, and serialize every generated value as one compact JSON line while preserving order and multiplicity.
story PARSE-001
summary: Implement jq lexical scanning. type: service kind: capability phase: 2 implements: FEATURE-PARSE-001.md covers: PARSE-001 context: ARCHITECTURE.md, sources/lexer.l, sources/parser.y, sources/jq.test stack: python.md provides: jq lexer and token stream consumes: JSON input and filter source depends: EXEC-003 acceptance: yes scope: target instructions: | Implement lexical handling for literals, identifiers, fields, bindings, keywords, operators, delimiters, comments, formats, and interpolation markers according to lexer.l.
story PARSE-002
summary: Implement literals, strings, escapes, and interpolation. type: service kind: capability phase: 2 implements: FEATURE-PARSE-002.md covers: PARSE-002 context: ARCHITECTURE.md, sources/lexer.l, sources/parser.y, sources/jq.test, sources/jq-manual.txt stack: python.md provides: JSON literals, jq strings, escapes, interpolation, format literals consumes: jq lexer and token stream depends: PARSE-001 acceptance: yes scope: target instructions: | Parse JSON escapes, Unicode strings, string interpolation, and @format syntax. Reject invalid escapes and preserve jq string semantics.
story PARSE-003
summary: Implement jq filter expression grammar. type: service kind: capability phase: 2 implements: FEATURE-PARSE-003.md covers: PARSE-003 context: ARCHITECTURE.md, sources/parser.y, sources/lexer.l, sources/jq.test stack: python.md provides: expression AST, precedence, pipes, commas, indexing, slicing, arrays, objects, operators consumes: jq lexer and token stream depends: PARSE-002 acceptance: yes scope: target instructions: | Build the expression parser and AST for composition, precedence, indexing, slicing, arrays, objects, unary operators, arithmetic, comparison, optional access, and assignment syntax.
story PARSE-004
summary: Implement declarations and control syntax parsing. type: service kind: capability phase: 2 implements: FEATURE-PARSE-004.md covers: PARSE-004 context: ARCHITECTURE.md, sources/parser.y, sources/lexer.l, sources/jq.test stack: python.md provides: declarations, conditionals, try/catch, reductions, foreach, labels, bindings, modules grammar consumes: expression AST depends: PARSE-003 acceptance: yes scope: target instructions: | Parse defs, bindings, destructuring, conditionals, try/catch, reduce, foreach, labels, breaks, import/include/module grammar, and required compile-time rejection cases without loading excluded module fixtures.
story CORE-001
summary: Implement the stream-valued filter evaluator. type: service kind: capability phase: 3 implements: FEATURE-CORE-001.md covers: CORE-001 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: ordered generator evaluator consumes: expression AST depends: PARSE-004 acceptance: yes scope: target instructions: | Evaluate every filter as an ordered generator supporting zero, one, or many outputs, backtracking, identity, iteration, empty, and range primitives.
story CORE-002
summary: Implement composition and Cartesian generator evaluation. type: service kind: capability phase: 3 implements: FEATURE-CORE-002.md covers: CORE-002 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: pipe, comma, argument, array, object, and binary composition consumes: ordered generator evaluator depends: CORE-001 acceptance: yes scope: target instructions: | Implement pipe and comma composition, Cartesian products across multi-output filters and arguments, collection, object construction, and generator ordering.
story CORE-003
summary: Implement empty, runtime errors, optional evaluation, and try. type: service kind: capability phase: 3 implements: FEATURE-CORE-003.md covers: CORE-003 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: empty, error, optional operator, try/catch, partial runtime output consumes: ordered generator evaluator depends: CORE-002 acceptance: yes scope: target instructions: | Implement runtime error propagation, suppression with ?, try/catch handling, empty streams, and partial output before a runtime error.
story CORE-004
summary: Implement jq truthiness, equality, and ordering. type: service kind: capability phase: 3 implements: FEATURE-CORE-004.md covers: CORE-004 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: truthiness, equality, inequality, comparison ordering consumes: ordered generator evaluator depends: CORE-003 acceptance: yes scope: target instructions: | Implement jq truthiness where only false and null are falsey, numeric equivalence, structural equality, and jq's total type ordering.
story VALUE-001
summary: Implement the jq value and numeric model. type: service kind: capability phase: 3 implements: FEATURE-VALUE-001.md covers: VALUE-001 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: null, boolean, number, string, array, object, NaN, infinity values consumes: JSON input reader depends: CORE-004 acceptance: yes scope: target instructions: | Implement jq values using standard-library representations, including special numeric values, literal-number preservation where required, and structural serialization behavior.
story VALUE-002
summary: Implement field and index access. type: service kind: capability phase: 3 implements: FEATURE-VALUE-002.md covers: VALUE-002 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: field access, index access, optional access, negative indices, missing values consumes: ordered generator evaluator, jq value model depends: VALUE-001 acceptance: yes scope: target instructions: | Implement object fields, array indices, string-key indexing, optional access, negative indices, missing-value null behavior, and access errors.
story VALUE-003
summary: Implement slices and collection iteration. type: service kind: capability phase: 3 implements: FEATURE-VALUE-003.md covers: VALUE-003 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: array slices, string slices, array iteration, object iteration consumes: field and index access depends: VALUE-002 acceptance: yes scope: target instructions: | Implement array and string slices, fractional and out-of-range bounds, iteration over arrays and objects, optional iteration, and generator behavior.
story VALUE-004
summary: Implement type, length, numeric predicates, conversions, and math. type: service kind: capability phase: 3 implements: FEATURE-VALUE-004.md covers: VALUE-004 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: type, length, utf8bytelength, numeric predicates, conversions, math builtins consumes: jq value model, generator evaluator depends: VALUE-003 acceptance: yes scope: target instructions: | Implement type and length primitives, UTF-8 byte length, numeric predicates, tonumber/toboolean/tostring, arithmetic primitives, and required math functions.
story FLOW-001
summary: Implement arithmetic and structural operators. type: service kind: capability phase: 4 implements: FEATURE-FLOW-001.md covers: FLOW-001 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: plus, minus, multiply, divide, modulo, negation, recursive merge, repetition, splitting consumes: jq value model, generator evaluator depends: VALUE-004 acceptance: yes scope: target instructions: | Implement typed arithmetic and structural operators, recursive object merge, string repetition, string division, array subtraction, modulo, and unary negation.
story FLOW-002
summary: Implement boolean and alternative operators. type: service kind: capability phase: 4 implements: FEATURE-FLOW-002.md covers: FLOW-002 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: and, or, not, defined-or, defined-or assignment consumes: generator evaluator, truthiness and comparison depends: FLOW-001 acceptance: yes scope: target instructions: | Implement Boolean operators, not, defined-or short-circuiting, generator-aware fallback behavior, and //=.
story FLOW-003
summary: Implement conditionals and exception flow. type: service kind: capability phase: 4 implements: FEATURE-FLOW-003.md covers: FLOW-003 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: if, then, elif, else, try, catch, optional control flow consumes: generator evaluator, runtime error model depends: FLOW-002 acceptance: yes scope: target instructions: | Implement branching over generator outputs, optional else behavior, elif chains, try/catch, and optional operators with correct stream and error semantics.
story FLOW-004
summary: Implement lexical labels and breaks. type: service kind: capability phase: 4 implements: FEATURE-FLOW-004.md covers: FLOW-004 context: ARCHITECTURE.md, sources/parser.y, sources/jq-manual.txt, sources/jq.test stack: python.md provides: label and break control flow consumes: generator evaluator, runtime error model depends: FLOW-003 acceptance: yes scope: target instructions: | Implement lexically scoped labels and break termination so the correct enclosing generator stops without leaking outputs.
story FLOW-005
summary: Implement reductions and iteration controls. type: service kind: capability phase: 4 implements: FEATURE-FLOW-005.md covers: FLOW-005 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: reduce, foreach, range, limit, skip, first, last, nth consumes: generator evaluator, bindings, labels depends: FLOW-004 acceptance: yes scope: target instructions: | Implement reducer state, foreach extraction, range variants, limit, skip, first, last, and nth with Cartesian arguments, backtracking, and short-circuiting.
story FLOW-006
summary: Implement recursive generator primitives. type: service kind: capability phase: 4 implements: FEATURE-FLOW-006.md covers: FLOW-006 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: while, until, repeat, recurse, recursive descent consumes: generator evaluator, runtime error model depends: FLOW-005 acceptance: yes scope: target instructions: | Implement recursive generators and recursive descent with correct termination, stream ordering, and recursion behavior.
story FUNC-001
summary: Implement lexical variable bindings. type: service kind: capability phase: 5 implements: FEATURE-FUNC-001.md covers: FUNC-001 context: ARCHITECTURE.md, sources/parser.y, sources/jq-manual.txt, sources/jq.test stack: python.md provides: as bindings, variable lookup, lexical scope, shadowing consumes: generator evaluator, parser AST depends: FLOW-006 acceptance: yes scope: target instructions: | Implement value bindings, lexical scope, shadowing, keyword identifiers, binding lifetime, and variable lookup across generator streams.
story FUNC-002
summary: Implement filter and value function parameters. type: service kind: capability phase: 5 implements: FEATURE-FUNC-002.md covers: FUNC-002 context: ARCHITECTURE.md, sources/parser.y, sources/jq-manual.txt, sources/builtin.jq, sources/jq.test stack: python.md provides: filter parameters, value parameters, function arities, Cartesian function calls consumes: lexical variable bindings, generator evaluator depends: FUNC-001 acceptance: yes scope: target instructions: | Implement user-defined filter and value parameters, multiple arities, closures, repeated filter invocation, and Cartesian argument semantics.
story FUNC-003
summary: Implement function definitions, scope, and recursion. type: service kind: capability phase: 5 implements: FEATURE-FUNC-003.md covers: FUNC-003 context: ARCHITECTURE.md, sources/parser.y, sources/jq-manual.txt, sources/jq.test stack: python.md provides: def declarations, lexical function scope, redefinition, recursion, forward/self references consumes: function parameters, lexical variable bindings depends: FUNC-002 acceptance: yes scope: target instructions: | Implement function definitions, lexical function scope, redefinitions by arity, recursive and self references, closures, and function backtracking.
story FUNC-004
summary: Implement destructuring patterns and alternatives. type: service kind: capability phase: 5 implements: FEATURE-FUNC-004.md covers: FUNC-004 context: ARCHITECTURE.md, sources/parser.y, sources/jq-manual.txt, sources/jq.test stack: python.md provides: array patterns, object patterns, missing bindings, ?// alternatives consumes: lexical bindings, function evaluator depends: FUNC-003 acceptance: yes scope: target instructions: | Implement array and object destructuring, null binding for missing members, alternative pattern backtracking, and final-error propagation.
story PATH-001
summary: Implement path discovery and projection. type: service kind: capability phase: 6 implements: FEATURE-PATH-001.md covers: PATH-001 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/builtin.jq, sources/jq.test stack: python.md provides: path, paths, pick consumes: accessors, recursive generators, destructuring depends: FUNC-004 acceptance: yes scope: target instructions: | Implement path expression discovery, recursive paths, filtered paths, and pick projections with valid path semantics and errors.
story PATH-002
summary: Implement path access and mutation primitives. type: service kind: capability phase: 6 implements: FEATURE-PATH-002.md covers: PATH-002 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/builtin.jq, sources/jq.test stack: python.md provides: getpath, setpath, delpaths consumes: path discovery and jq value model depends: PATH-001 acceptance: yes scope: target instructions: | Implement nested path reads, creation and updates, deletion, array expansion, invalid-path handling, negative indices, depth limits, and immutable results.
story PATH-003
summary: Implement deletion and assignment operators. type: service kind: capability phase: 6 implements: FEATURE-PATH-003.md covers: PATH-003 context: ARCHITECTURE.md, sources/parser.y, sources/jq-manual.txt, sources/builtin.jq, sources/jq.test stack: python.md provides: del, =, |=, +=, -=, *=, /=, %=, //= consumes: path discovery, getpath, setpath, delpaths depends: PATH-002 acceptance: yes scope: target instructions: | Implement immutable deletion, plain assignment, update assignment, arithmetic assignment, defined-or assignment, multi-path behavior, and generator-valued RHS semantics.
story PATH-004
summary: Implement complex assignment edge cases. type: service kind: capability phase: 6 implements: FEATURE-PATH-004.md covers: PATH-004 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: iterated assignment, empty updates, array expansion, invalid and deep paths consumes: deletion and assignment operators depends: PATH-003 acceptance: yes scope: target instructions: | Complete iterated paths, empty updates, array expansion, invalid paths, negative and NaN indices, string-slice restrictions, and depth-limit behavior.
story DATA-001
summary: Implement collection transformation builtins. type: service kind: capability phase: 7 implements: FEATURE-DATA-001.md covers: DATA-001 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: map, map_values, select, add, flatten, transpose, combinations, walk consumes: generator evaluator, assignment operators depends: PATH-004 acceptance: yes scope: target instructions: | Implement collection transformation builtins and recursive walk while preserving stream semantics, empty behavior, and immutable updates.
story DATA-002
summary: Implement sorting and grouping builtins. type: service kind: capability phase: 7 implements: FEATURE-DATA-002.md covers: DATA-002 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: sort, sort_by, group_by, unique, unique_by, min, max, keyed extrema consumes: jq comparison and ordering depends: DATA-001 acceptance: yes scope: target instructions: | Implement sorting, keyed sorting, grouping, uniqueness, minimum, maximum, and keyed variants using jq ordering and stable generator-derived keys.
story DATA-003
summary: Implement object-entry and containment builtins. type: service kind: capability phase: 7 implements: FEATURE-DATA-003.md covers: DATA-003 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: keys, keys_unsorted, has, in, inside, contains, to_entries, from_entries, with_entries consumes: jq value model, comparison and ordering depends: DATA-002 acceptance: yes scope: target instructions: | Implement object and array key utilities, containment relations, entry conversions, and with_entries while preserving object ordering semantics where required.
story DATA-004
summary: Implement index and membership utilities. type: service kind: capability phase: 7 implements: FEATURE-DATA-004.md covers: DATA-004 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: indices, index, rindex, bsearch, all, any, isempty, IN consumes: collection transformations, comparison and generator evaluation depends: DATA-003 acceptance: yes scope: target instructions: | Implement string and array index searches, binary search, all/any short-circuiting, isempty, and SQL-style IN variants.
story TEXT-001
summary: Implement string manipulation builtins. type: service kind: capability phase: 8 implements: FEATURE-TEXT-001.md covers: TEXT-001 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: trim, ltrim, rtrim, prefix/suffix, case, explode, implode, split, join consumes: jq string values, generator evaluator depends: DATA-004 acceptance: yes scope: target instructions: | Implement Unicode-aware trimming, prefix and suffix operations, ASCII case conversion, codepoint conversion, split, join, and string validation errors.
story TEXT-002
summary: Implement JSON and output format filters. type: service kind: capability phase: 8 implements: FEATURE-TEXT-002.md covers: TEXT-002 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: tostring, tojson, fromjson, @text, @json, @html, @uri, @urid, @csv, @tsv, @sh, @base64, @base64d consumes: jq value model, string manipulation depends: TEXT-001 acceptance: yes scope: target instructions: | Implement JSON conversion and all required text, HTML, URI, CSV, TSV, shell, and Base64 format filters with interpolation and escaping semantics.
story TEXT-003
summary: Implement regular-expression filters. type: service kind: capability phase: 8 implements: FEATURE-TEXT-003.md covers: TEXT-003 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: test, match, capture, scan, split, splits, sub, gsub consumes: jq strings, generator evaluator depends: TEXT-002 acceptance: yes scope: target instructions: | Implement regex matching with standard-library re features mapped to jq flags, named captures, offsets, streams, splitting, substitution, and global replacement.
story TEXT-004
summary: Implement date and time filters. type: service kind: capability phase: 8 implements: FEATURE-TEXT-004.md covers: TEXT-004 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md provides: fromdate, todate, strptime, strftime, strflocaltime, gmtime, localtime, mktime consumes: jq strings and numbers depends: TEXT-003 acceptance: yes scope: target instructions: | Implement UTC date parsing and formatting plus required low-level time conversions using Python standard-library time and datetime facilities.
story IO-001
summary: Implement input stream controls. type: service kind: capability phase: 9 implements: FEATURE-IO-001.md covers: IO-001 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md, common.md provides: input, inputs, input_filename, input_line_number consumes: JSON stdin reader depends: TEXT-004 acceptance: yes scope: target instructions: | Implement input and inputs over the fixed stdin interface and provide the documented filename and line-number primitives.
story IO-002
summary: Implement diagnostics and stderr output. type: service kind: capability phase: 9 implements: FEATURE-IO-002.md covers: IO-002 context: ARCHITECTURE.md, sources/jq-manual.txt, sources/jq.test stack: python.md, common.md provides: debug, stderr, halt_error consumes: process exit and diagnostic contract depends: IO-001 acceptance: yes scope: target instructions: | Implement debug and stderr side effects, halt_error output and exit behavior, and preserve stdout/stderr separation.
story IO-003
summary: Implement streaming transformations. type: service kind: capability phase: 9 implements: FEATURE-IO-003.md covers: IO-003 context: ARCHITECTURE.md, sources/builtin.jq, sources/jq-manual.txt, sources/jq.test stack: python.md provides: tostream, fromstream, truncate_stream consumes: generator evaluator, path primitives depends: IO-002 acceptance: yes scope: target instructions: | Implement jq streaming representations and conversion utilities for the supplied streaming cases.
story CONF-001
summary: Stage and validate immutable conformance assets. type: foundational kind: test harness phase: 1 implements: FEATURE-CONF-001.md covers: CONF-001 context: COMPASS.md, sources/INSTRUCTIONS.md, sources/run_conformance.py, sources/full_test.sh, sources/exclusions.txt, sources/jq.test, sources/jq-manual.txt, sources/parser.y, sources/lexer.l, sources/builtin.jq stack: python.md, common.md provides: sources/ conformance corpus, manual, grammar, harness, exclusions, full-test script consumes: target application root depends: architecture-foundation acceptance: yes scope: both instructions: | Stage the supplied sources verbatim under sources/. Validate corpus parsing and exclusion consistency by importing the harness parsers directly; do not modify or execute the candidate.
story CONF-002
summary: Provide scoped conformance verification. type: service kind: test harness phase: 9 implements: FEATURE-CONF-002.md covers: CONF-002 context: COMPASS.md, sources/run_conformance.py stack: python.md, common.md provides: scoped conformance execution with JQ candidate binding consumes: ./jq, sources/run_conformance.py depends: IO-003, CONF-001 acceptance: yes scope: target instructions: | Verify that scoped acceptance invocations execute selected corpus cases with JQ extended from the inherited environment and machine-readable results.
story CONF-003
summary: Run the complete jq conformance corpus. type: service kind: test harness phase: 10 implements: FEATURE-CONF-003.md covers: CONF-003 accepts: st-001 context: COMPASS.md, sources/full_test.sh, sources/run_conformance.py, sources/exclusions.txt, sources/jq.test stack: python.md, common.md provides: complete jq conformance release verification consumes: ./jq, sources/full_test.sh depends: EXEC-001, EXEC-002, EXEC-003, PARSE-001, PARSE-002, PARSE-003, PARSE-004, CORE-001, CORE-002, CORE-003, CORE-004, VALUE-001, VALUE-002, VALUE-003, VALUE-004, FLOW-001, FLOW-002, FLOW-003, FLOW-004, FLOW-005, FLOW-006, FUNC-001, FUNC-002, FUNC-003, FUNC-004, PATH-001, PATH-002, PATH-003, PATH-004, DATA-001, DATA-002, DATA-003, DATA-004, TEXT-001, TEXT-002, TEXT-003, TEXT-004, IO-001, IO-002, IO-003, CONF-001, CONF-002 acceptance: yes scope: target instructions: | Run the supplied full-test script as the terminal verification. Assert its exit status is zero, print captured stdout and stderr for diagnosis, and do not reinterpret or filter the corpus.
DECISIONS.json
[] </pblock>
<pblock label="Plan continuation" kind="continuation">
Continuation
Stage 1 is complete. Drydock accepted and froze the complete TOPOLOGY.md declaration before starting this Blueprint-authoring stage. The full planning context above remains authoritative.
The ledger below states exactly what Drydock accepted, what is still missing, and what came back defective. Treat it as fact.
Your job
Emit exactly the artifacts in the ledger's Current batch, in the stated order. Nothing else.
- Do not re-emit an accepted artifact. Its content is already held and will not be read again.
- Do not emit a deferred artifact. Drydock supplies it in a later bounded batch.
- Do not emit or amend
TOPOLOGY.md; Stage 1 is complete and frozen. - Do not emit
DECISIONS.json; it was captured with the topology in Stage 1. - Do not restate your plan, summarize progress, apologize, or explain the interruption.
- Do not emit
MANIFEST.md; Drydock serializes it from the declaration. - Use exactly the same delimited block format as before, including the mandatory
=== END ARTIFACT === line for every file. The name is typed once, at the open; the closing delimiter is that constant token and never carries the name.
- An artifact listed as defective must be emitted again in full, corrected. A partial or patched
version is not accepted.
- Emit each missing artifact under the exact filename the ledger names. A filename that does not
match its declaration cannot be accepted.
Budget
Author the Current batch one Blueprint at a time. For each Blueprint, emit its opening delimiter, its complete file body, and its matching closing delimiter. Only after the closing delimiter is written may the next Blueprint's opening delimiter be emitted.
A whole artifact is progress; a truncated one is not. Never pre-emit opening delimiters, outline several files at once, nest one artifact inside another, or use one closing delimiter for several files. If the whole Current batch cannot fit, finish and close the current artifact, then end the response. Drydock retries every unproduced artifact from the same batch.
The only legal sequence is:
=== BEGIN ARTIFACT FIRST-NAME ===
{complete first file}
=== END ARTIFACT ===
=== BEGIN ARTIFACT SECOND-NAME ===
{complete second file}
=== END ARTIFACT ===Ledger
Accepted (40) — already held, do not re-emit: ARCHITECTURE.md FEATURE-CORE-001.md FEATURE-CORE-002.md FEATURE-CORE-003.md FEATURE-CORE-004.md FEATURE-DATA-001.md FEATURE-DATA-002.md FEATURE-DATA-003.md FEATURE-DATA-004.md FEATURE-EXEC-001.md FEATURE-EXEC-002.md FEATURE-EXEC-003.md FEATURE-FLOW-001.md FEATURE-FLOW-002.md FEATURE-FLOW-003.md FEATURE-FLOW-004.md FEATURE-FLOW-005.md FEATURE-FLOW-006.md FEATURE-FUNC-001.md FEATURE-FUNC-002.md FEATURE-FUNC-003.md FEATURE-FUNC-004.md FEATURE-IO-001.md FEATURE-IO-002.md FEATURE-PARSE-001.md FEATURE-PARSE-002.md FEATURE-PARSE-003.md FEATURE-PARSE-004.md FEATURE-PATH-001.md FEATURE-PATH-002.md FEATURE-PATH-003.md FEATURE-PATH-004.md FEATURE-TEXT-001.md FEATURE-TEXT-002.md FEATURE-TEXT-003.md FEATURE-TEXT-004.md FEATURE-VALUE-001.md FEATURE-VALUE-002.md FEATURE-VALUE-003.md FEATURE-VALUE-004.md
Current batch (4) — emit exactly these, in this order: IO-003 -> FEATURE-IO-003.md CONF-001 -> FEATURE-CONF-001.md CONF-002 -> FEATURE-CONF-002.md CONF-003 -> FEATURE-CONF-003.md
Deferred (0) — Drydock will provide later batches; do not emit them now. </pblock>