You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AST-powered code documentation tool for generating optimized `llms.txt` files from codebases.
11
8
12
9
## Overview
13
10
14
-
`ast-doc` is a Rust CLI tool that combines broad file traversal with deep AST-based semantic parsing to create optimized documentation. It uses a four-stage pipeline:
11
+
`ast-doc` is a Rust CLI that combines broad file traversal with deep AST-based semantic parsing to create optimized documentation. It uses a four-stage pipeline:
15
12
16
13
1.**Ingestion** — File discovery, git metadata capture, directory tree generation
17
14
2.**Parser** — tree-sitter AST extraction with pre-computed strategy variants
- BDD via `features/*.feature` plus `just bdd` remains the acceptance contract.
149
-
- Example-based crate-local unit tests remain the default inner loop for named business cases and edge cases.
150
-
-`proptest` lives in the ordinary `cargo test` path when the rule is an invariant across many valid inputs.
151
-
- Advanced modes are opt-in: use `cargo-fuzz` only for hostile-input or `unsafe`-heavy crates, and add Criterion only when the work has a real performance target.
90
+
# Run full CI
91
+
just ci
152
92
153
-
## BDD + TDD Workflow
154
-
155
-
1. Write a failing Gherkin scenario in `features/*.feature`.
156
-
2. Write a failing crate-local unit or property test in the affected crate to drive the inner loop.
157
-
3. Implement the smallest shared Rust API needed to satisfy the test.
158
-
4. Run `just test` to exercise deterministic unit tests and any `proptest` properties together.
159
-
5. Re-run `just bdd` to confirm the acceptance scenario passes.
160
-
161
-
Use example-based unit tests for named business cases and edge cases that should stay readable. Use `proptest` when the rule is an invariant, such as totals matching line-item arithmetic or checkout always emptying the cart.
162
-
163
-
## Project Convention
164
-
165
-
- Put executable crates under `bin/*`
166
-
- Put reusable library crates under `crates/*`
167
-
- Keep shared dependencies in root `[workspace.dependencies]`
168
-
169
-
## Common Commands
170
-
171
-
```bash
172
-
just format
93
+
# Individual steps
173
94
just lint
174
95
just test
175
96
just bdd
176
-
just test-all
177
97
just build
178
98
```
179
99
180
-
`just test` runs the usual `cargo test --all-features` flow, so colocated `proptest` coverage in crate test modules stays in the standard inner loop rather than a separate test layer.
100
+
## Feature Flags
181
101
182
-
## Conditional Benchmark Guidance
102
+
| Feature | Description | Default |
103
+
|---------|-------------|---------|
104
+
|`lang-rust`| Rust parser | ✓ |
105
+
|`lang-pack`| 50+ languages via tree-sitter-language-pack | ✓ |
|`all-languages`| Enable all language parsers | ✗ |
111
+
|`hotpath`| Profiling instrumentation | ✗ |
183
112
184
-
Do not add Criterion or a benchmark scaffold to every new workspace by default. Most business logic and CRUD-style crate work should stay on the ordinary `just test` plus `just bdd` path unless the planned feature has an explicit latency SLA, throughput target, or known hot path worth measuring.
113
+
## Testing
185
114
186
-
When performance-sensitive code appears, add Criterion only in the affected crate and benchmark the hot path that carries the requirement. That keeps the default template lean while still using the standard Rust benchmark tool when the work genuinely needs measurement.
115
+
-**BDD**: Gherkin scenarios in `features/*.feature`, run with `just bdd`
116
+
-**Unit tests**: Colocated `#[cfg(test)]` modules, run with `just test`
117
+
-**Property tests**: `proptest` in standard `cargo test` flow
187
118
188
-
## Conditional Fuzzing Guidance
119
+
## Project Structure
189
120
190
-
Do not add `cargo-fuzz` targets to every new workspace by default. The standard Rust template is enough for ordinary business logic, CRUD-style services, and shared domain crates that only handle trusted or well-formed inputs.
191
-
192
-
Reach for fuzzing when a specific crate starts handling hostile input or high-risk memory behavior, especially when it:
193
-
194
-
- parses free-form text or file formats,
195
-
- implements protocol framing or message decoding,
196
-
- decodes binary formats or other untrusted payloads,
197
-
- or relies on substantial `unsafe` code.
198
-
199
-
When one of those conditions applies, enable fuzzing only in the affected crate and use the normal Cargo workflow rather than baking a `fuzz/` directory into every starter:
200
-
201
-
```bash
202
-
cd crates/<crate-name>
203
-
cargo fuzz init
204
-
cargo fuzz run <target-name>
121
+
```text
122
+
bin/ CLI binary crates
123
+
crates/ Reusable library crates
124
+
features/ BDD Gherkin scenarios
205
125
```
206
126
207
-
That keeps the default template lean while still pointing parser-like, protocol, binary-decoding, or `unsafe`-heavy crates to the standard `cargo-fuzz` layout when they actually need it.
0 commit comments