perf: optimize memory and pre-calculate hints

GEMINI.md

@@ -0,0 +1,41 @@
+# Conductor Context
+
+If a user mentions a "plan" or asks about the plan, and they have used the conductor extension in the current session, they are likely referring to the `conductor/tracks.md` file or one of the track plans (`conductor/tracks/<track_id>/plan.md`).
+
+## Universal File Resolution Protocol
+
+**PROTOCOL: How to locate files.**
+To find a file (e.g., "**Product Definition**") within a specific context (Project Root or a specific Track):
+
+1.  **Identify Index:** Determine the relevant index file:
+    -   **Project Context:** `conductor/index.md`
+    -   **Track Context:**
+        a. Resolve and read the **Tracks Registry** (via Project Context).
+        b. Find the entry for the specific `<track_id>`.
+        c. Follow the link provided in the registry to locate the track's folder. The index file is `<track_folder>/index.md`.
+        d. **Fallback:** If the track is not yet registered (e.g., during creation) or the link is broken:
+            1. Resolve the **Tracks Directory** (via Project Context).
+            2. The index file is `<Tracks Directory>/<track_id>/index.md`.
+
+2.  **Check Index:** Read the index file and look for a link with a matching or semantically similar label.
+
+3.  **Resolve Path:** If a link is found, resolve its path **relative to the directory containing the `index.md` file**.
+    -   *Example:* If `conductor/index.md` links to `./workflow.md`, the full path is `conductor/workflow.md`.
+
+4.  **Fallback:** If the index file is missing or the link is absent, use the **Default Path** keys below.
+
+5.  **Verify:** You MUST verify the resolved file actually exists on the disk.
+
+**Standard Default Paths (Project):**
+- **Product Definition**: `conductor/product.md`
+- **Tech Stack**: `conductor/tech-stack.md`
+- **Workflow**: `conductor/workflow.md`
+- **Product Guidelines**: `conductor/product-guidelines.md`
+- **Tracks Registry**: `conductor/tracks.md`
+- **Tracks Directory**: `conductor/tracks/`
+
+**Standard Default Paths (Track):**
+- **Specification**: `conductor/tracks/<track_id>/spec.md`
+- **Implementation Plan**: `conductor/tracks/<track_id>/plan.md`
+- **Metadata**: `conductor/tracks/<track_id>/metadata.json`
+

conductor/code_styleguides/general.md

@@ -0,0 +1,23 @@
+# General Code Style Principles
+
+This document outlines general coding principles that apply across all languages and frameworks used in this project.
+
+## Readability
+- Code should be easy to read and understand by humans.
+- Avoid overly clever or obscure constructs.
+
+## Consistency
+- Follow existing patterns in the codebase.
+- Maintain consistent formatting, naming, and structure.
+
+## Simplicity
+- Prefer simple solutions over complex ones.
+- Break down complex problems into smaller, manageable parts.
+
+## Maintainability
+- Write code that is easy to modify and extend.
+- Minimize dependencies and coupling.
+
+## Documentation
+- Document *why* something is done, not just *what*.
+- Keep documentation up-to-date with code changes.

conductor/index.md

@@ -0,0 +1,14 @@
+# Project Context
+
+## Definition
+- [Product Definition](./product.md)
+- [Product Guidelines](./product-guidelines.md)
+- [Tech Stack](./tech-stack.md)
+
+## Workflow
+- [Workflow](./workflow.md)
+- [Code Style Guides](./code_styleguides/)
+
+## Management
+- [Tracks Registry](./tracks.md)
+- [Tracks Directory](./tracks/)

conductor/product-guidelines.md

@@ -0,0 +1,13 @@
+# Product Guidelines
+
+## Documentation & Messaging
+- **Technical and Precise:** Documentation should prioritize technical accuracy and provide detailed specifications. Language should be formal and clear, targeting a developer-centric audience while remaining accessible for integration purposes.
+
+## Error Handling & Feedback
+- **Structured and Actionable:** Errors must be categorized with specific error codes and include actionable suggestions for resolution. The goal is to minimize developer friction and allow users to self-correct configuration or data issues.
+
+## Extensibility & Architecture
+- **Modular and Pluggable:** The system should be designed to allow for easy extension. Developers should be able to plug in new renderers, data models, or processing logic without requiring modifications to the core engine. This ensures the project remains adaptable to diverse bibliographic needs.
+
+## Visual Identity & Branding
+- **Modern and Professional:** The project's interfaces (CLI, web-based tools) should reflect reliability and high performance. This is achieved through clean typography, a consistent professional color palette, and a focus on clarity and speed in user interactions.

conductor/product.md

@@ -0,0 +1,14 @@
+# Initial Concept
+
+## Vision
+To provide a simpler, easier-to-extend, and more featureful successor to CSL (Citation Style Language). The project aims to modernize citation processing with a Rust-based model that generates JSON schemas, ensuring alignment between code and configuration while offering high performance for both batch and interactive contexts.
+
+## Target Audience
+- **Software Developers:** Developers building bibliographic tools (like Zotero, Pandoc, or other reference managers) who require a robust, high-performance citation engine to handle complex formatting and data processing tasks.
+
+## Core Features
+- **High-Performance Processing:** Optimized for both batch processing (e.g., Markdown, LaTeX documents) and real-time interactive use (e.g., GUI reference managers), ensuring speed and efficiency.
+- **Simplified Style Configuration:** Moves logic from complex templates to extensible option groups, making style creation and maintenance easier for users and developers.
+- **Modern Standards:** Native support for EDTF (Extended Date/Time Format) and other modern idioms, replacing legacy string parsing with structured data handling.
+- **Schema-Driven Development:** JSON schemas are generated directly from the Rust model, ensuring consistency and providing a contract for external tools and domain experts.
+- **Cross-Platform Compatibility:** Designed to work across desktop, web, and CLI environments.

conductor/setup_state.json

@@ -0,0 +1 @@
+{"last_successful_step": "3.3_initial_track_generated"}

conductor/tech-stack.md

@@ -0,0 +1,25 @@
+# Technology Stack
+
+## Core Language & Runtime
+- **Rust:** The primary programming language, chosen for its memory safety, performance, and modern tooling. The project uses a Cargo workspace (resolver 2) to manage its components.
+
+## Data Serialization & Standards
+- **Serialization:** Native support for **JSON** and **YAML** using `serde` and `serde_json`.
+- **Date/Time Standards:** Adherence to **EDTF** (Extended Date/Time Format) for robust and standardized date handling.
+- **Schema Generation:** Automated generation of JSON schemas from Rust models to ensure cross-language compatibility.
+
+## Project Architecture
+- **Monorepo (Workspace):**
+  - `csln`: Core library defining the data models for bibliography, citations, and styles.
+  - `processor`: The citation processing engine and rendering logic.
+  - `cli`: A command-line interface for interacting with the processor.
+
+## Development & Quality Tools
+- **Build System:** Cargo
+- **Linting:** `cargo clippy` (with workspace-level lint configurations)
+- **Formatting:** `cargo fmt`
+- **Testing:** `cargo test` for unit and integration tests.
+- **Benchmarking:** `cargo bench` (using `criterion` or similar) for performance tracking in `csln-processor`.
+
+## Deployment & Distribution
+- **Binary:** Single, statically-linked binaries for the CLI and schema generation tools.

conductor/tracks.md

@@ -0,0 +1,8 @@
+# Project Tracks
+
+This file tracks all major tracks for the project. Each track has its own detailed plan in its respective folder.
+
+---
+
+- [ ] **Track: Implement a YAML-based integration test suite for the processor to verify citation rendering across different styles and input types.**
+  *Link: [./conductor/tracks/yaml_tests_20260125/](./conductor/tracks/yaml_tests_20260125/)*

conductor/tracks/yaml_tests_20260125/index.md

@@ -0,0 +1,5 @@
+# Track yaml_tests_20260125 Context
+
+- [Specification](./spec.md)
+- [Implementation Plan](./plan.md)
+- [Metadata](./metadata.json)

conductor/tracks/yaml_tests_20260125/metadata.json

@@ -0,0 +1,8 @@
+{
+  "track_id": "yaml_tests_20260125",
+  "type": "feature",
+  "status": "new",
+  "created_at": "2026-01-25T09:15:00Z",
+  "updated_at": "2026-01-25T09:15:00Z",
+  "description": "Implement a YAML-based integration test suite for the processor to verify citation rendering across different styles and input types."
+}

conductor/tracks/yaml_tests_20260125/plan.md

@@ -0,0 +1,20 @@
+# Implementation Plan: YAML-based Integration Test Suite
+
+## Phase 1: Foundation and Data Models
+- [ ] Task: Define the `TestCase` struct and associated serialization logic in `processor/tests/integration.rs`.
+    - [ ] Create `processor/tests/integration.rs`.
+    - [ ] Define the data models for the YAML test format.
+- [ ] Task: Conductor - User Manual Verification 'Phase 1: Foundation and Data Models' (Protocol in workflow.md)
+
+## Phase 2: Test Runner Implementation
+- [ ] Task: Implement the test discovery and execution loop.
+    - [ ] Write logic to find all YAML files in `processor/tests/data/`.
+    - [ ] Write logic to deserialize and run each test case.
+- [ ] Task: Conductor - User Manual Verification 'Phase 2: Test Runner Implementation' (Protocol in workflow.md)
+
+## Phase 3: Initial Test Cases and Validation
+- [ ] Task: Add initial test cases for standard styles (APA, Chicago).
+    - [ ] Create `processor/tests/data/apa_basic.yaml`.
+    - [ ] Create `processor/tests/data/chicago_basic.yaml`.
+- [ ] Task: Verify overall test coverage and handle edge cases (e.g., missing fields in YAML).
+- [ ] Task: Conductor - User Manual Verification 'Phase 3: Initial Test Cases and Validation' (Protocol in workflow.md)

conductor/tracks/yaml_tests_20260125/spec.md

@@ -0,0 +1,19 @@
+# Specification: YAML-based Integration Test Suite
+
+## Objective
+Create a data-driven integration test suite using YAML files to validate the `csln-processor`'s rendering accuracy across various styles and reference types.
+
+## Requirements
+- **YAML Test Format:** Define a schema that includes:
+    - `name`: Description of the test case.
+    - `style`: The CSL style configuration (YAML/JSON).
+    - `bibliography`: The input reference data.
+    - `citation`: The citation to be rendered.
+    - `expected`: The expected string output.
+- **Test Runner:** A Rust test in the `processor` crate that iterates over all `.yaml` files in a dedicated test data directory.
+- **Dynamic Execution:** The runner should dynamically load the style and data, execute the processor, and assert equality with the expected output.
+
+## Architecture
+- **Crate:** `processor`
+- **Test File:** `processor/tests/integration.rs`
+- **Data Directory:** `processor/tests/data/*.yaml`