jsonatapy 2.1.4__tar.gz → 2.1.6__tar.gz

jsonatapy-2.1.6/.serena/.gitignore

@@ -0,0 +1,2 @@
+/cache
+/project.local.yml

jsonatapy-2.1.6/.serena/memories/architecture.md

@@ -0,0 +1,86 @@
+## Evaluator/compiler architecture (non-obvious internals)
+
+### JValue (src/value.rs)
+```rust
+pub enum JValue {
+    Null, Bool(bool), Number(f64),
+    String(Rc<str>), Array(Rc<Vec<JValue>>), Object(Rc<IndexMap<String, JValue>>),
+    Undefined, Lambda { lambda_id, params, name, signature },
+    Builtin { name }, Regex { pattern, flags },
+    #[cfg(feature = "python")] LazyPyDict(Rc<lazy::LazyPyDict>),
+}
+```
+- O(1) clone for every variant (Rc bump for heap types).
+- Constructors: `JValue::string(..)`, `::array(..)`, `::lambda(..)`, `::builtin(..)`.
+- Gotchas: `Rc<str>` doesn't satisfy `Borrow<String>` (use `&**s` for HashMap lookups);
+  `Rc<Vec>` can't `.into_iter()` (use `.iter()` or `.to_vec()`/`Rc::make_mut()` to mutate).
+
+### Null vs Undefined
+JSONata distinguishes explicit `null` from "not present" `Undefined`; the tree-walker
+historically produced `Null` for almost all "field not found" cases (a pre-existing bug fixed by
+migrating ~20 hand-written call sites in evaluator.rs — fast paths, multi-step loops,
+out-of-range array index, `apply_stages`, etc. — plus ~20 more downstream sites that assumed
+"Null means missing": `signature.rs::validate_and_coerce`, builtin arg guards, arithmetic
+explicit-null branches, `??`, `$not`/`$string`/`$append`/`$spread`). Reference pattern for
+correct "present vs missing" semantics: `compiled_field_step` in evaluator.rs — Object: field-or-
+Undefined; Array: map+flatten+skip-Undefined; other: Undefined. Exception: `AstNode::Variable`
+(unbound `$var`) deliberately still returns `Null`, not `Undefined` — only path/field "not found"
+semantics were migrated, not unbound-variable semantics. If tree-walker code decides
+present-vs-missing and a value isn't propagating as expected, suspect a leftover pre-migration
+site (grep `unwrap_or(JValue::Null)` / `JValue::Null =>` near field-access code).
+
+### Lambda representation
+- Lambdas live in the scope stack's `lambdas: HashMap<String, StoredLambda>`; `JValue::Lambda`
+  only carries a `lambda_id` (+ params/name/signature) referencing that map.
+- `lambda_id` MUST come from `Evaluator`'s monotonic `next_lambda_id`/`fresh_lambda_id()` counter,
+  never a pointer-derived id (`format!("{:p}", ast_node)`) — an AST node's address is fixed per
+  source site but each evaluation of a recursive/repeated lambda creates a new closure instance;
+  pointer-derived ids alias distinct instances in the scope map, causing ~0.5%-frequency
+  intermittent wrong-closure bugs (spurious T2010 / U1001 depth-limit errors). This was a real,
+  hard-to-reproduce bug (issue #35) — reproducible only in a tight pure-Rust loop with a fresh
+  `Evaluator` per iteration.
+- `collect_lambda_ids()` transitively follows a `StoredLambda`'s captured_env.
+- `:=` with a lambda RHS stores only in the lambdas map, not in regular bindings.
+
+### Compilation pipeline (bytecode fast path)
+`evaluator::try_compile_expr(ast)` → `CompiledExpr` (IR) → `compiler::BytecodeCompiler::compile`
+→ `BytecodeProgram` (flat `Vec<Instr>`) → `peephole()` folds (`PushData+GetField` →
+`GetDataField`, `GetVar+GetField` → `GetVarField`, elides `Not+Not`) → `vm::Vm::new(bc).run(...)`.
+`JsonataExpression` (lib.rs) caches `bytecode: OnceCell<Option<BytecodeProgram>>`; all 4 evaluate
+entrypoints try the VM first and fall back to the tree-walker.
+
+Key correctness rules baked into the compiler/VM (violate these and specific test-suite groups
+regress):
+- And/Or compile to jump-based short-circuit code, not a binary instruction — required for
+  exprs like `foo = '' or $number(foo) = 0` where evaluating rhs unconditionally would be wrong.
+- Arithmetic/comparison ops carry compile-time `ExplicitNull` flags (`Add(lhs_en, rhs_en)`,
+  `CmpLt(...)`) for correct T2002/T2010 errors.
+- `get_field_cached` flattens one level of nested arrays when mapping (matches `compiled_field_step`)
+  — required for `flattening/case001`.
+- `MakeArray` skips undefined and flattens one level; but a "complex" `ArrayConstruct` (elements
+  marked `is_nested=true`) must NOT flatten and falls back to `EvalFallback`.
+- `FieldPath` with filter predicates always falls back to `eval_compiled` (tree-walker) — filters
+  aren't compiled.
+- Numeric predicates like `[0]`, `[1]` in a path are INDEX access, not boolean filters — must
+  fall back to the tree-walker in `try_compile_path`.
+- Peephole 2-instruction folds must remap BOTH consumed instructions' jump targets to the same
+  new address, or jumps land mid-fold.
+
+### Lambda compilation (Phase 3)
+`StoredLambda.compiled_body: Option<CompiledExpr>`, compiled at definition time via
+`try_compile_expr_with_allowed_vars`. Fast path in `invoke_stored_lambda` skips scope push/pop
+when: body is compiled AND no signature AND not a thunk AND no captured functions. HOF fast
+paths (`$map`/`$filter`/`$reduce`) handle both inline lambdas and stored-lambda variables.
+`compiled_body` is deliberately set to `None` (forcing tree-walker) for: transform body,
+ChainPipe composition, TCO thunks, partial-application body markers — these are known-uncompiled
+sites, not bugs.
+
+### LazyPyDict (Phase 5, Python-only perf path)
+`JValue::LazyPyDict(Rc<LazyPyDict>)` (src/lazy.rs) lets field access on a Python dict skip full
+materialization into `JValue::Object`; `to_object()` must skip `Undefined` entries when
+materializing (absent fields must not appear as explicit nulls). Every code path that switches
+on `JValue` object/array shape (sort keys, `$keys`/`$spread`/`$lookup`/`$merge`/`$sort`,
+`$each`/`$sift`, the `@` tuple binding, `apply_transform_deep`) needs an explicit `LazyPyDict` arm
+or a materialize-first step — it's easy to add a new object-shaped builtin and forget this.
+Benefits sparse field-access patterns (2–5x speedup measured); dense full-object access can
+slightly regress vs. eager materialization — don't assume it's a strict win everywhere.

jsonatapy-2.1.6/.serena/memories/conventions.md

@@ -0,0 +1,32 @@
+## Codebase conventions
+
+- **Mirror the JS reference structurally**: module names and function names should track
+  `jsonata-js`'s `src/*.js` (parser.js → parser.rs, functions.js → functions.rs, etc.) so
+  upstream diffs are easy to port. Don't restructure Rust modules away from this mapping
+  without strong reason.
+- **Two execution paths, one semantics**: tree-walking `Evaluator` (evaluator.rs) is the
+  reference/fallback implementation; `compiler.rs`/`vm.rs` is a bytecode fast path that falls
+  back to the tree-walker (`EvalFallback`) for anything not compilable. New JSONata semantics
+  should be correct in the tree-walker first (it's the oracle used for compatibility testing),
+  then optionally fast-pathed into the compiler/VM — see `mem:architecture` for the split's
+  concrete rules (short-circuit and/or, explicit-null flags, array flattening, etc.).
+- **`JValue` (src/value.rs) is the value type**, not `serde_json::Value` — `Rc`-wrapped
+  variants for O(1) clone (`String(Rc<str>)`, `Array(Rc<Vec<JValue>>)`, `Object(Rc<IndexMap<...>>)`).
+  Lambdas/builtins/regexes are first-class `JValue` variants, not tagged JSON objects.
+  `serde_json::Value` is only used at I/O boundaries (JSON string parsing, test fixtures).
+  See `mem:architecture` for the full variant list and common gotchas (`Rc<str>` vs
+  `Borrow<String>`, `Rc<Vec>` iteration/mutation).
+- **Null vs Undefined are semantically distinct** (JSONata quirk carried over from JS) — do not
+  conflate them when writing new "field not found" or "value missing" logic; see
+  `mem:architecture` for the correct reference pattern and history of a subtle prior bug here.
+- **Rust style**: 2021 edition, `cargo fmt` + `cargo clippy -- -D warnings` (zero warnings,
+  non-negotiable), `Result<T, E>` for fallible ops, rustdoc `///` on public APIs, comments should
+  explain *deviations from JS behavior*, not restate what code does.
+- **Python style**: PEP 8 via ruff, type hints required on public APIs (mypy strict), ruff
+  double-quote/100-col formatting — no black despite CLAUDE.MD mentioning it (ruff format is
+  what's actually configured in pyproject.toml).
+- **Test-driven against the JS suite**: the JSONata-js reference suite
+  (`tests/python/test_reference_suite.py` over the `tests/jsonata-js` submodule) is the
+  compatibility oracle. Any evaluator/compiler change should be checked against the FULL
+  1258-case suite, not just a hand-picked subset — subtle regressions have historically hidden
+  in low-frequency edge cases (e.g. lambda id aliasing at ~0.5% call frequency).

jsonatapy-2.1.6/.serena/memories/core.md

@@ -0,0 +1,39 @@
+## jsonatapy: source map
+
+Rust-based Python extension implementing JSONata (JSON query/transform language), targeting
+100% compatibility with the reference `jsonata-js` v2.1.0 test suite (1258/1258 passing).
+Two published artifacts from one codebase: `jsonata-core` (crates.io, pure Rust) and
+`jsonatapy` (PyPI, PyO3 wrapper). See root `CLAUDE.MD` for full project charter/design goals —
+this memory only covers what CLAUDE.MD omits or what changes faster than that doc.
+
+### Layout
+- `src/` — Rust crate (`jsonata-core`). Core files: `ast.rs`, `parser.rs` (+ `src/parser/README.md`),
+  `evaluator.rs` (~8700 lines, tree-walking evaluator — the reference/fallback path),
+  `compiler.rs` + `vm.rs` (bytecode compiler + VM — the fast path, falls back to the
+  tree-walker for anything not compilable), `value.rs` (`JValue`), `functions.rs`, `datetime.rs`,
+  `signature.rs`, `lib.rs` (PyO3 Python boundary).
+- `python/jsonatapy/` — thin Python package; `__init__.py` re-exports the compiled `_jsonatapy`
+  extension module and adds optional orjson-backed `json_dumps`/`json_loads`.
+- `tests/jsonata-js/` — git submodule, the upstream JS reference suite (source of the 1258 cases).
+- `tests/python/test_reference_suite.py` — runs the submodule's cases against the compiled extension.
+- `tests/integration_test.rs` — Rust-side integration tests (separate from inline `#[cfg(test)]`).
+- `benchmarks/` — cross-language perf comparisons (Python/JS/Rust) driving the "faster than JS" claim.
+- `scripts/setup-uv.sh` — canonical from-scratch dev bootstrap (installs uv+Rust, builds, runs both test suites).
+
+### Further memories
+- `mem:tech_stack` — toolchain, package managers, version pins.
+- `mem:suggested_commands` — day-to-day dev/build/test commands.
+- `mem:conventions` — code style and architectural conventions specific to this codebase.
+- `mem:task_completion` — what to run before considering a change done.
+- `mem:architecture` — JValue/evaluator/compiler pipeline internals, non-obvious invariants.
+
+### Non-obvious invariants
+- Two independent execution paths must stay behaviorally identical: the tree-walking
+  `Evaluator` (evaluator.rs) and the bytecode `Vm` (vm.rs/compiler.rs). The VM is preferred when
+  compilable; anything it can't compile falls back to the tree-walker. Changes to evaluation
+  semantics generally need to be made in both, or the fallback path silently diverges.
+- Repo root has multiple stale/duplicate Python venvs (`.venv`, `.venv-wsl`, `.venv.bak`) — don't
+  assume one is canonical without checking; `uv` manages its own env from `pyproject.toml`/`uv.lock`.
+- Serena's language auto-detection for this project defaults to `typescript` (misled by the
+  `tests/jsonata-js` submodule / `node_modules`) unless `.serena/project.yml`'s `languages:` list
+  is corrected to `[rust, python]` — check this after any Serena project reset.

jsonatapy-2.1.6/.serena/memories/memory_maintenance.md

@@ -0,0 +1,33 @@
+# Memory Maintenance
+
+## Discovery Model
+
+- Core principle: progressive discovery through references, building a graph of memories.
+- Initially, agents are provided with the list of all memories (names only).
+- Agents should read `mem:core` as the top-level entry point (graph root).
+  This memory should contain references to other memories covering major project domains.
+  The referenced memories shall, in turn, shall contain references to even more specific memories, and so on.
+  The depth of the graph shall depend on the project complexity.
+- Use topics/folders to group related memories in order to make the content structure explicit.
+  Folders can mirror project structure (e.g. modules like frontend/backend) or topics like debugging, architecture, etc.
+- Memory references must use a mem: prefix inside backticks, e.g. `mem:frontend/core`.
+  The surrounding text should clearly indicate when to read the memory/which content to expect.
+  The text should provide more precise guidance than the memory name alone, 
+  i.e. avoid a reference like "frontend debugging: `mem:frontend/debugging` and instead make clear which aspects of frontend debugging are covered.
+- Memories themselves should not contain information about when to read them; this is the responsibility of the referring memory.
+
+## Style
+
+Dense agent notes, not prose docs. Prefer invariants, terse bullets. 
+Avoid obvious context, rationale, and examples unless they prevent likely mistakes. 
+Keep guidance durable and generalizable, not task-local.
+
+## Add/update threshold
+
+Add or update memories only with stable, non-obvious project conventions that avoid complex rediscovery in the future.
+Do not add: quick-read facts; generic language/framework knowledge; one-off task notes; volatile line-level details; behavior likely to change soon.
+
+## Maintenance Actions
+
+- Renaming memories: References are updated automatically if handled via Serena's memory rename tool.
+- Checking for stale memories (e.g. after deletion): Call `serena memories check` for a report.

jsonatapy-2.1.6/.serena/memories/suggested_commands.md

@@ -0,0 +1,40 @@
+## Suggested commands (Linux/WSL)
+
+### Build
+```bash
+maturin develop --release   # build Rust ext + install into active venv (release, use for perf-sensitive testing)
+maturin develop              # debug build, faster to compile, use for quick iteration
+maturin build --release      # produce a wheel in dist/
+```
+
+### Test
+```bash
+cargo test                                              # Rust unit + tests/integration_test.rs
+uv run pytest tests/python/test_reference_suite.py       # 1258 JSONata-js reference cases (primary compat gate)
+uv run pytest tests/python/ -v                           # full Python suite
+uv run pytest tests/python/test_functions.py::test_string_functions -v   # single test
+```
+Reference suite depends on the `tests/jsonata-js` git submodule being initialized:
+`git submodule update --init --recursive`.
+
+### Lint / format (zero-warnings policy on Rust side)
+```bash
+cargo fmt
+cargo clippy -- -D warnings
+uv run ruff check python/ tests/
+uv run ruff format python/ tests/
+uv run mypy python/
+```
+
+### Benchmark
+```bash
+cargo bench                       # Criterion, uses `bench` feature
+uv run python benchmarks/python/... # cross-language comparisons (see benchmarks/ for entrypoints)
+```
+
+### Linux/WSL-specific notes
+- Standard GNU coreutils apply (no BSD `find`/`sed` quirks).
+- Compiled extension `.so` files live directly in `python/jsonatapy/` (`_jsonatapy.cpython-3XX-x86_64-linux-gnu.so`)
+  after `maturin develop` — one per Python minor version tested.
+- Repo has leftover `.venv`, `.venv-wsl`, `.venv.bak` dirs; prefer `uv run` which resolves its
+  own environment rather than assuming a particular venv is active.

jsonatapy-2.1.6/.serena/memories/task_completion.md

@@ -0,0 +1,23 @@
+## Definition of done
+
+Run all of these before considering a change complete; all are zero-tolerance (project charter
+says 100% test compatibility and zero-clippy-warnings are non-negotiable):
+
+```bash
+cargo fmt --check          # or `cargo fmt` to auto-fix, then verify
+cargo clippy -- -D warnings
+cargo test
+maturin develop --release  # rebuild extension so Python tests exercise the new Rust code
+uv run pytest tests/python/test_reference_suite.py   # full 1258-case JS compat suite
+uv run pytest tests/python/ -v                       # rest of the Python suite
+uv run ruff check python/ tests/
+uv run mypy python/
+```
+
+If the change touches evaluator/compiler semantics, confirm both execution paths agree:
+the reference suite should pass under the default (VM-preferred) path AND when the VM/compiler
+fast path is bypassed (forcing the tree-walker) — see `mem:architecture` for how prior migrations
+verified this dual-path parity.
+
+If the change is user-facing (new function, new signature, changed error), update
+`CHANGELOG.md` per Keep a Changelog format (per CLAUDE.MD).

jsonatapy-2.1.6/.serena/memories/tech_stack.md

@@ -0,0 +1,19 @@
+## Tech stack
+
+- **Rust**: edition 2021, `rust-version = "1.70"` (stable channel only, no nightly features per
+  CLAUDE.MD). Crate name `jsonata-core` (lib name `jsonata_core`), cdylib+rlib.
+- **Key Rust deps**: `pyo3` 0.29 (optional, feature `python`), `serde`/`serde_json` (preserve_order),
+  `simd-json` 0.17 (optional, feature `simd`, default-on — SIMD JSON parsing fast path),
+  `indexmap` (ordered maps for JSONata objects), `regex`, `chrono`, `thiserror`, `stacker`
+  (stack growth for deep recursion), `rand`.
+- **Cargo features**: `default = ["simd"]`, `simd` (dep:simd-json), `python` (dep:pyo3,
+  enables the PyO3 boundary), `bench` (exposes `_bench` facade for Criterion).
+- **Python**: >=3.10, published wheels for 3.10–3.14. Build backend: **maturin** (module name
+  `jsonatapy._jsonatapy`, python-source = `python`).
+- **Package manager**: **uv** (uv.lock present) — prefer `uv run <cmd>` over bare `pip`/`python`.
+- **Python dev tooling**: ruff (lint+format, line-length 100, double quotes, target py310),
+  mypy (strict mode), pytest (+pytest-cov, pytest-xdist for parallel runs).
+- **Benchmarking**: Criterion (Rust, `cargo bench`, `evaluator_bench`), plus Python-side
+  benchmarks comparing against `jsonata` (JS) and `jsonata-rs`.
+- **Docs**: mkdocs + mkdocs-material (`docs/`, `mkdocs.yml`), not Sphinx despite CLAUDE.MD
+  mentioning Sphinx — mkdocs is what's actually wired up in pyproject.toml `[project.optional-dependencies.docs]`.

jsonatapy-2.1.6/.serena/project.yml

@@ -0,0 +1,160 @@
+# the name by which the project can be referenced within Serena/when chatting with the LLM.
+project_name: "jsonatapy"
+
+# list of languages for which language servers are started (LSP backend only); choose from:
+#   ada                 al                  angular             ansible             bash
+#   bsl                 clojure             cpp                 cpp_ccls            crystal
+#   csharp              csharp_omnisharp    cue                 dart                elixir
+#   elm                 erlang              fortran             fsharp              gdscript
+#   go                  groovy              haskell             haxe                hlsl
+#   html                java                json                julia               kotlin
+#   latex               lean4               lua                 luau                markdown
+#   matlab              msl                 nix                 ocaml               pascal
+#   perl                php                 php_phpactor        php_phpantom        powershell
+#   python              python_jedi         python_pyrefly      python_ty           r
+#   rego                ruby                ruby_solargraph     rust                scala
+#   scss                solidity            svelte              swift               systemverilog
+#   terraform           toml                typescript          typescript_vts      vue
+#   yaml                zig
+#   (This list may be outdated; generated with scripts/print_language_list.py;
+#   For the current list, see values of Language enum here:
+#   https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py)
+# For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.)
+# Note:
+#   - For C, use cpp
+#   - For JavaScript, use typescript
+#   - For Angular projects, use angular (subsumes typescript+html; requires `npm install` in the project root)
+#   - For Svelte projects, use svelte (subsumes typescript/javascript for .svelte projects; requires npm)
+#   - For SCSS / Sass / plain CSS, use scss (some-sass-language-server handles all three)
+#   - For Free Pascal/Lazarus, use pascal
+# Special requirements:
+#   Some languages require additional setup/installations.
+#   See here for details: https://oraios.github.io/serena/01-about/020_programming-languages.html#language-servers
+# When using multiple languages, the first language server that supports a given file will be used for that file.
+# The first language is the default language and the respective language server will be used as a fallback.
+# Note that when using the JetBrains backend, language servers are not used and this list is correspondingly ignored.
+languages:
+- rust
+- python
+
+# the encoding used by text files in the project
+# For a list of possible encodings, see https://docs.python.org/3.11/library/codecs.html#standard-encodings
+encoding: "utf-8"
+
+# optional shell command to run before the language backend (LSP or JetBrains) is initialised.
+# the command runs in the project root directory and is only executed if the project is trusted
+# (see trusted_project_path_patterns in the global configuration).
+# serena waits for the command to exit: a non-zero exit code is logged as an error but does not
+# abort activation. a per-project timeout (activation_command_timeout, default 180s) is the safety
+# backstop for non-terminating commands; on expiry the process is killed and activation continues.
+# example: activation_command: "npx nx run-many -t build"
+activation_command:
+
+# maximum time in seconds to wait for activation_command to complete before killing it (default 180s).
+# must be a positive number.
+activation_command_timeout: 180
+
+# line ending convention to use when writing source files.
+# Possible values: unset (use global setting), "lf", "crlf", or "native" (platform default)
+# This does not affect Serena's own files (e.g. memories and configuration files), which always use native line endings.
+line_ending:
+
+# The language backend to use for this project.
+# If not set, the global setting from serena_config.yml is used.
+# Valid values: LSP, JetBrains
+# Note: the backend is fixed at startup. If a project with a different backend
+# is activated post-init, an error will be returned.
+language_backend:
+
+# whether to use project's .gitignore files to ignore files
+ignore_all_files_in_gitignore: true
+
+# advanced configuration option allowing to configure language server-specific options.
+# Maps the language key to the options.
+# The settings are considered only if the project is trusted (see global configuration to define trusted projects).
+# See https://oraios.github.io/serena/02-usage/050_configuration.html#language-server-specific-settings
+ls_specific_settings: {}
+
+# list of workspace folder paths (LSP backend only).
+# These folders will be used to build up Serena's symbol index.
+# Paths must be within the project root and should thus be relative to the project root.
+# Furthermore, the paths should not be filtered by ignore settings.
+# Default setting: The entire project root folder (".") is considered.
+# In (large) monorepos, this can be used to index only subfolders of the project root, e.g.
+#   ls_workspace_folders:
+#     - "./subproject1"
+#     - "./subproject2"
+ls_workspace_folders: ["."]
+
+# list of additional workspace folder paths for cross-package reference support.
+# Paths can be absolute or relative to the project root.
+# Each folder is registered as an LSP workspace folder, enabling language servers to discover
+# symbols and references across package boundaries, but these folders are not indexed by Serena,
+# i.e. the respective symbols will not be found using Serena's symbol search tools.
+# Example:
+#   additional_workspace_folders:
+#     - ../sibling-package
+#     - ../shared-lib
+ls_additional_workspace_folders: []
+
+# list of additional paths to ignore in this project.
+# Same syntax as gitignore, so you can use * and **.
+# Note: global ignored_paths from serena_config.yml are also applied additively.
+ignored_paths: []
+
+# whether the project is in read-only mode
+# If set to true, all editing tools will be disabled and attempts to use them will result in an error
+# Added on 2025-04-18
+read_only: false
+
+# list of tool names to exclude.
+# This extends the existing exclusions (e.g. from the global configuration)
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
+excluded_tools: []
+
+# list of tools to include that would otherwise be disabled (particularly optional tools that are disabled by default).
+# This extends the existing inclusions (e.g. from the global configuration).
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
+included_optional_tools: []
+
+# fixed set of tools to use as the base tool set (if non-empty), replacing Serena's default set of tools.
+# This cannot be combined with non-empty excluded_tools or included_optional_tools.
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
+fixed_tools: []
+
+# list of mode names that are to be activated by default, overriding the setting in the global configuration.
+# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
+# If the setting is undefined/empty, the default_modes from the global configuration (serena_config.yml) apply.
+# Otherwise, this overrides the setting from the global configuration (serena_config.yml).
+# Therefore, you can set this to [] if you do not want the default modes defined in the global config to apply
+# for this project.
+# This setting can, in turn, be overridden by CLI parameters (--mode).
+# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
+default_modes:
+
+# list of mode names to be activated additionally for this project, e.g. ["query-projects"]
+# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
+# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
+added_modes:
+
+# initial prompt for the project. It will always be given to the LLM upon activating the project
+# (contrary to the memories, which are loaded on demand).
+initial_prompt: ""
+
+# time budget (seconds) per tool call for the retrieval of additional symbol information
+# such as docstrings or parameter information.
+# This overrides the corresponding setting in the global configuration; see the documentation there.
+# If null or missing, use the setting from the global configuration.
+symbol_info_budget:
+
+# list of regex patterns which, when matched, mark a memory entry as read‑only.
+# Extends the list from the global configuration, merging the two lists.
+read_only_memory_patterns: []
+
+# list of regex patterns for memories to completely ignore.
+# Matching memories will not appear in list_memories or activate_project output
+# and cannot be accessed via read_memory or write_memory.
+# To access ignored memory files, use the read_file tool on the raw file path.
+# Extends the list from the global configuration, merging the two lists.
+# Example: ["_archive/.*", "_episodes/.*"]
+ignored_memory_patterns: []