jacobian 0.2.0a0__tar.gz

jacobian-0.2.0a0/.agents/skills/discover-math-capabilities/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: discover-math-capabilities
+description: Mine row-level mathematical datasets, known solutions, formal artifacts, research cases, agent traces, and maintained backends for recurring mathematical moves that justify additions or changes to Jacobian's capability portfolio. Use when asked what mathematical tools Jacobian should add, expand, split, consolidate, improve, or retire; when extracting tool ideas from proofs, counterexamples, transcripts, datasets, or failed attempts; or when turning public cases into typed capability proposals and reproduction cases. This skill performs open workflow mining with answers visible; use evaluate-math-capabilities for held-out comparative evaluation.
+---
+
+# Discover Math Capabilities
+
+Determine what Jacobian should expose by reconstructing mathematical work from
+source evidence. Keep answers, successful methods, failures, and review
+artifacts visible during discovery. The objective is to find reusable
+mathematical operations and trust boundaries, not to measure autonomous model
+performance.
+
+## Establish the source bundle
+
+Declare the scope and inputs before proposing changes. Distinguish:
+
+- problem statements, known solutions, counterexamples, and formal proofs;
+- agent transcripts, tool calls, failed attempts, and user corrections;
+- public datasets and historical mathematical cases;
+- the current capability catalog, source, descriptors, and tests;
+- maintained external systems and their documented contracts; and
+- hypotheses unsupported by repeated workflow evidence.
+
+Treat machine-checkable proofs, replayable certificates, and explicit objects
+as the strongest process evidence. Treat expert discussions and curated
+databases as useful context. Treat blogs, news, social posts, and shared chats
+as leads until their primary artifacts are inspected.
+
+Record dataset revision, license, redistribution constraints, and contamination
+risk when material. Do not copy a large dataset into the repository merely to
+mine it.
+
+## Inspect rows and primary artifacts
+
+Use landing pages, indexes, social posts, and dataset cards to map the source
+bundle, not as substitutes for its mathematical contents. Inspect enough
+primary examples to see variation across:
+
+- successful proofs, counterexamples, constructions, and formal checks;
+- failed attempts, false premises, rejected proofs, and reviewer corrections;
+- easy and hard cases, domains, labels, and source families; and
+- natural-language, executable, and machine-checkable artifacts.
+
+For datasets, inspect the schema and identifiable rows at a pinned revision.
+For repositories and pull requests, inspect the exact statement, decisive
+object or proof, computation, checker, and review corrections. For transcripts,
+extract tool-visible actions, artifacts, failures, and user corrections; do not
+treat hidden reasoning or persuasive narration as mathematical evidence. Follow
+papers, forums, blogs, and social claims to their primary objects before
+crediting a method.
+
+Keep downloaded corpora, source-bundle inventories, scratch ledgers, and dated
+investigations in temporary or ignored storage unless a durable research record
+is explicitly requested. Commit generalized process guidance, stable
+reproduction fixtures, benchmark cases, contracts, and implementation—not a
+one-off URL inventory.
+
+## Inspect Jacobian first
+
+Read `AGENTS.md`, then consult these files as needed:
+
+- `docs/explanation/goals.md`
+- `docs/reference/tools.md`
+- `docs/reference/capability-workflow-evaluations.md`
+
+Inspect `capability://catalog`, `capability.describe`, source, and tests before
+calling an operation missing. Classify each observed problem as one of:
+
+- capability exists and works;
+- capability exists but was unavailable or hard to discover;
+- capability was selected or parameterized poorly;
+- capability lacks a needed operation or contract field;
+- verification or artifact handoff is missing;
+- environment, budget, or authorization prevented use; or
+- mathematical reasoning, rather than tooling, was the bottleneck.
+
+Prefer better examples, errors, payloads, batching, or discovery when those
+address the observed problem. Do not create a new ID for every backend function
+or friction event.
+
+## Reconstruct the mathematical process
+
+For each representative case, inspect the statement, successful resolution,
+failed routes, intermediate artifacts, and verification method. Build a compact
+move ledger:
+
+| Case or row | Inputs before move | Mathematical operation | Output or artifact | Downstream use | Failure or alternative | Verification |
+| --- | --- | --- | --- | --- | --- | --- |
+
+Treat each consequential transition as a move episode:
+
+```text
+available mathematical state
+→ operation performed
+→ inspectable mathematical output
+→ changed downstream decision
+→ independent check, open obligation, or failure
+```
+
+Do not summarize a whole proof or transcript as one move. Split exact
+evaluation, transformation, construction, search, comparison, reduction, and
+replay when their outputs remain independently useful to an agent.
+
+Identify the smallest agent-visible mathematical outcome that would have
+changed a consequential step. Examples include retrieving a premise,
+constructing an object, computing an invariant, transforming a claim,
+enumerating a finite family, finding a witness, comparing candidates, or
+checking a certificate. These are prompts, not a closed taxonomy.
+
+For each proposed outcome, state:
+
+- the exact supporting episodes and source locators;
+- the input available at that point;
+- the typed output and inline summary;
+- durable intermediate artifacts and relationships;
+- exactness, scope, completeness, and determinism;
+- the provider and version requirements;
+- the independent verification boundary; and
+- the counterfactual reason the outcome would help an agent; and
+- what the operation still cannot establish.
+
+Cluster repeated moves by mathematical outcome, not by dataset name or backend
+API call. Prefer domain-owned IDs such as `graph.enumerate.nonisomorphic` or
+`polynomial.compute.groebner_basis` over universal object or solver schemas.
+Normally require the move to recur in at least two independent cases or source
+families. Admit a single-source exception only for a fundamental primitive with
+clear reuse, a maintained backend, and a strong verification boundary.
+
+Distinguish a missing operation from a strategy gap. If current capabilities
+already expose the necessary intermediate outcomes, improve discovery,
+descriptors, examples, or a reusable agent skill instead of adding another
+capability.
+
+## Research existing systems
+
+Before recommending custom mathematics, inspect maintained proof assistants,
+CAS systems, solvers, optimization tools, databases, and domain libraries that
+already implement the outcome. Verify behavior against current source and
+official documentation. Prefer a thin pinned adapter over reimplementation.
+
+Record backend readiness, deployment and license constraints, reproducibility
+requirements, and whether it emits a replayable certificate. Search,
+retrieval, generation, and computation produce evidence; they do not verify
+their own conclusions.
+
+## Define the trust boundary
+
+For exact conclusions, identify an independent checker bound to the exact
+claim, domain semantics, candidate, scope, certificate format, and checker
+identity. If independent replay is unavailable, label the attainable assurance
+and open obligation instead of treating provider output as verified.
+
+Preserve useful intermediate objects, failures, transformations, and
+obligations. Do not replace them with an opaque `solve_conjecture` workflow.
+Agent-visible mathematical atomicity matters; backend-call atomicity does not.
+
+## Apply the candidate gate
+
+Create a candidate record before implementation:
+
+| Gate | Required evidence |
+| --- | --- |
+| Recurrence | Independent move episodes or a justified fundamental-primitive exception |
+| Leverage | The output changes a consequential downstream mathematical decision |
+| Atomicity | One coherent agent-visible outcome with useful intermediate artifacts |
+| Portfolio fit | A real gap, split, consolidation, or improvement rather than a duplicate |
+| Backend readiness | Maintained implementation, versioning, deployment, and license understood |
+| Contract honesty | Typed input/output with explicit exactness, scope, completeness, and determinism |
+| Trust boundary | Independent replay path or an explicit unverified obligation |
+| Reproduction | At least one primary public case can exercise the proposed contract |
+| Evaluation hypothesis | A held-out comparison could distinguish value from persuasive replay |
+
+Reject or defer candidates that are dataset-specific wrappers, opaque
+multi-stage workflows, mechanical backend-function mirrors, answer generators,
+self-verifying searches, or operations whose failure state could be mistaken
+for a theorem. Record the failed gate and evidence; a rejection ledger prevents
+the same weak idea from being repeatedly rediscovered.
+
+## Reproduce known cases
+
+Use a small selection of public cases to test whether a proposed contract can
+reproduce known work:
+
+- the capability accepts the available source artifacts;
+- its output exposes the mathematically useful intermediate state;
+- scope and completeness are truthful;
+- failures remain non-conclusions; and
+- independent replay works when claimed.
+
+These are public reproduction and regression cases. They show contract fitness,
+not general portfolio value. Do not call a capability beneficial merely because
+it replays the examples that inspired it.
+
+## Hand off comparative questions
+
+When the proposal is concrete enough to ask whether it improves autonomous
+performance, hand it to `evaluate-math-capabilities`. Supply:
+
+- the complete candidate record and supporting move episodes;
+- the capability hypothesis and counterfactual benefit;
+- public reproduction cases;
+- plausible wrong paths and false-certification risks;
+- current portfolio overlap and the proposed control ablation;
+- candidate backends and checker boundaries;
+- applicable datasets and contamination notes; and
+- the metrics that could distinguish success from a persuasive replay.
+
+Do not construct hidden oracles during open workflow mining unless the user also
+asks for an evaluation.
+
+## Report
+
+Lead with the repeated process evidence and the resulting portfolio decisions.
+Use a compact table:
+
+| Evidence | Mathematical move | Current support or gap | Proposed change | Backend | Verification boundary | Public reproduction | Decision |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+Separate:
+
+- capabilities already covering apparent gaps;
+- additions, expansions, splits, consolidation, or retirement;
+- research-only hypotheses;
+- rejected candidates and the gates they failed;
+- limitations and unresolved proof gaps; and
+- proposals ready for comparative evaluation.
+
+Continue until the remaining ideas lack repeated workflow evidence, meaningful
+leverage, agent-visible atomicity, backend readiness, an honest contract,
+trustworthy verification boundaries, portfolio distinctness, or a testable
+value hypothesis. “No more good candidates” is a supported portfolio decision,
+not a requirement to manufacture another capability.

jacobian-0.2.0a0/.agents/skills/discover-math-capabilities/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Discover Math Capabilities"
+  short_description: "Mine recurring mathematical moves into tool proposals"
+  default_prompt: "Use $discover-math-capabilities to mine these source rows and artifacts for recurring mathematical moves that justify Jacobian capability changes."

jacobian-0.2.0a0/.agents/skills/evaluate-math-capabilities/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: evaluate-math-capabilities
+description: Consume evidence-backed capability candidates and design, implement, run, and interpret Jacobian-specific model-in-the-loop evaluations that measure whether a mathematical operation or portfolio change improves autonomous agent outcomes. Use when asked to benchmark a Jacobian capability, compare baseline and treatment portfolios, create held-out mathematical cases or independent oracles, detect workflow leakage, measure correctness or false certification, evaluate retrieval or tool composition, or decide whether to keep, expand, split, consolidate, rank, or retire a capability. Use discover-math-capabilities first when the question is what to build rather than whether a concrete proposal helps.
+---
+
+# Evaluate Math Capabilities
+
+Determine whether a concrete Jacobian capability or portfolio change helps
+agents on new mathematical work. Keep the strategy agent-owned and score
+outcomes and evidence, not a preferred sequence of calls.
+
+## Confirm evaluation readiness
+
+Start from a concrete intervention:
+
+- a capability or portfolio delta;
+- a discovery candidate record with supporting move episodes;
+- one expected counterfactual benefit;
+- a runnable baseline and treatment;
+- public reproduction evidence or a stable contract;
+- an independently judgeable mathematical outcome; and
+- at least one plausible wrong or falsely certified path.
+
+If the operation, contract, backend, or intended mathematical outcome is still
+unclear, return the question to `discover-math-capabilities`. Evaluation should
+not invent the product hypothesis it is meant to test.
+
+## Audit the discovery handoff
+
+Confirm that the handoff identifies:
+
+- exact source rows, traces, proofs, or counterexamples that motivated the move;
+- the before-state, operation, output artifact, downstream use, and verification
+  boundary for each supporting episode;
+- current portfolio overlap and why composition does not already close the gap;
+- public reproduction cases separated from held-out scored cases;
+- candidate backend, contract, failure semantics, and checker boundary;
+- contamination risks and plausible falsely persuasive paths; and
+- the predicted autonomous behavior that should change under treatment.
+
+Use missing handoff evidence as a reason to return the candidate to discovery,
+not as an invitation to fill the gap with evaluation fixtures.
+
+## Inspect the repository harness
+
+Read `AGENTS.md` and inspect:
+
+- `docs/reference/capability-workflow-evaluations.md`
+- `benchmarks/agent_ab.py`
+- `benchmarks/ab_cases/`
+- `src/jacobian/eval_telemetry.py`
+- `tests/integration/test_agent_ab_benchmark.py`
+- the relevant capability descriptors, checkers, and contracts.
+
+Extend the established case schemas and runner when practical. Do not create a
+parallel benchmark framework for one experiment.
+
+## State the comparison
+
+Freeze the evaluation question before running either condition. Define:
+
+- **control**: current portfolio or a targeted ablation;
+- **treatment**: the same portfolio plus the intervention;
+- the same model, reasoning effort, prompt, budget, environment, and visible
+  artifacts;
+- randomized condition order and recorded fixture/order seeds;
+- multiple repetitions when making comparative claims; and
+- the exact capability-availability snapshot for each condition.
+
+Prescribed-tool cases measure contract usability and conformance. Autonomous
+portfolio cases let the agent choose operations and measure portfolio value.
+Do not confuse the two. If the agent is told the successful sequence mined from
+the source cases, report contract replay rather than autonomous portfolio value.
+
+Change one intervention dimension at a time. Evaluate a capability delta,
+descriptor change, example, ranking policy, or reusable strategy skill as
+separate treatments when the question is which one caused the improvement.
+
+## Build the held-out case
+
+Give the agent the smallest natural task and source bundle available before the
+answer. Keep the answer, scoring discriminator, and checker-only data outside
+the evaluated workspace.
+
+A hidden oracle means inaccessible to the agent during the run, not necessarily
+secret forever. It may be an independently generated object, a checker,
+withheld dataset fields, or a public answer used with an explicit contamination
+warning.
+
+For every case, freeze:
+
+- visible input bundle and output schema;
+- oracle version and provenance;
+- accepted conclusions and alternative valid strategies;
+- exact evidence bindings required for stronger assurance;
+- one tempting incomplete, misbound, or semantically mismatched route;
+- facts that must remain uncertain; and
+- source lineage, cutoff date, and contamination risk.
+
+Prefer generated or transformed variants for scored claims. Public solved
+problems are valuable regressions but weak evidence of generalization.
+Prefer held-out source families when practical. If a scored case descends from
+the discovery corpus, record the lineage and transform it enough that success
+requires using the mathematical operation rather than recalling the mined
+answer or workflow.
+
+## Keep the oracle independent
+
+Use an implementation independent of the capability being evaluated. The
+oracle must bind its judgment to the exact claim, semantics, candidate, scope,
+and certificate where applicable. It must reject:
+
+- provider output treated as self-verification;
+- bounded failure to find a witness treated as proof;
+- incomplete enumeration reported as exhaustive;
+- an isomorphic or altered object substituted without provenance;
+- a proof of a mismatched formal statement; and
+- timeout, cancellation, or execution failure converted into a conclusion.
+
+Place hidden oracle material where the evaluated agent cannot read it. Avoid
+answer leakage through filenames, comments, caches, neighboring artifacts, or
+transcript instructions.
+
+## Score outcomes before efficiency
+
+Make these primary:
+
+- oracle correctness;
+- false certification;
+- execution and completion state;
+- scope and completeness accuracy;
+- evidence and verification-record bindings; and
+- acceptance of mathematically valid alternative strategies.
+
+Among semantically correct runs, measure:
+
+- wall time;
+- input and output tokens;
+- total and successful tool calls;
+- tool and parameter errors;
+- repeated or irrelevant calls; and
+- infrastructure work reported by the agent.
+
+A faster wrong answer loses. A verifier-backed bounded result must not be
+scored as a proof outside its checked scope.
+
+## Validate the evaluation
+
+Before trusting a comparison:
+
+1. Confirm a capable agent has enough visible information to solve the task.
+2. Run or reason through one known-good report.
+3. Run or reason through at least one tempting bad report.
+4. Confirm the bad path fails for the intended mathematical reason.
+5. Confirm alternate correct strategies can pass.
+6. Test the case loader, scorer, telemetry parsing, and checker replay.
+7. Version the case whenever its source, oracle, contract, or environment
+   changes.
+
+Do not weaken a case to make the treatment pass. Record an unavailable backend,
+tool failure, or insufficient prompt as its own failure class.
+
+## Run and preserve evidence
+
+Use the repository runner and keep generated results under its ignored results
+directory. Record:
+
+- repository tree and capability/provider versions;
+- model and reasoning settings;
+- order and fixture seeds;
+- prompts and capability availability;
+- raw transcripts and structured reports;
+- oracle and scorer outcomes; and
+- validation actually run.
+
+Never expose hidden oracle contents in the treatment prompt or model workspace.
+Do not report provider sampling as deterministic when no generation seed is
+available.
+
+## Interpret the result
+
+Separate:
+
+- capability value;
+- discovery or descriptor quality;
+- parameterization and contract usability;
+- workflow or answer leakage;
+- backend reliability;
+- verification and provenance behavior; and
+- mathematical reasoning limits.
+
+Choose a portfolio action supported by the transcripts:
+
+- keep or expand;
+- improve discovery, examples, defaults, or errors;
+- split useful intermediate outcomes;
+- consolidate redundant outcomes;
+- add independent verification;
+- rerun with more repetitions;
+- defer; or
+- retire.
+
+Experimental availability need not wait for evaluation. Use results to guide
+recommendations, defaults, consolidation, and retirement rather than turning
+evaluation into an access gate.
+
+Feed failures back to discovery with the failed candidate gate. A capability
+that is unused because its outcome has no leverage is different from one that
+is valuable but undiscoverable, difficult to parameterize, unavailable in the
+environment, or missing an independent checker. Do not respond to a strategy,
+descriptor, or evaluation-design failure by manufacturing another operation.
+
+## Report
+
+Return:
+
+- the discovery candidate and supporting evidence lineage;
+- the frozen question and intervention;
+- case and oracle provenance;
+- baseline and treatment definitions;
+- correctness and false-certification results;
+- cost and tool-use metrics for correct runs;
+- transcript-derived failure classes;
+- contamination and proof gaps;
+- the justified portfolio action; and
+- exact reproduction commands.
+
+State whether the result is a harness validation, public regression, pilot, or
+comparative performance claim. Do not promote a single pair to a statistically
+powered conclusion.

jacobian-0.2.0a0/.agents/skills/evaluate-math-capabilities/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Evaluate Math Capabilities"
+  short_description: "Test candidate operations with leakage-resistant evals"
+  default_prompt: "Use $evaluate-math-capabilities to turn this discovery candidate into a held-out Jacobian portfolio evaluation."

jacobian-0.2.0a0/.devcontainer/devcontainer.json

@@ -0,0 +1,26 @@
+{
+    "name": "Jacobian Development",
+    "image": "mcr.microsoft.com/devcontainers/python:3.12",
+    "features": {
+        "ghcr.io/astral-sh/setup-uv:1": {}
+    },
+    "customizations": {
+        "vscode": {
+            "extensions": [
+                "charliermarsh.ruff",
+                "ms-python.mypy-type-checker",
+                "ms-python.python"
+            ],
+            "settings": {
+                "python.defaultInterpreterPath": ".venv/bin/python",
+                "editor.formatOnSave": true,
+                "editor.codeActionsOnSave": {
+                    "source.fixAll.ruff": "explicit",
+                    "source.organizeImports.ruff": "explicit"
+                }
+            }
+        }
+    },
+    "postCreateCommand": "make setup",
+    "remoteUser": "vscode"
+}

jacobian-0.2.0a0/.devin/config.local.json

@@ -0,0 +1,10 @@
+{
+  "permissions": {
+    "allow": [
+      "Exec(ls)",
+      "Exec(git diff)",
+      "Exec(git log)",
+      "Exec(git status)"
+    ]
+  }
+}

jacobian-0.2.0a0/.dockerignore

@@ -0,0 +1,8 @@
+.git
+.jacobian
+.venv
+benchmarks/results
+build
+dist
+lean/.lake
+__pycache__

jacobian-0.2.0a0/.env.example

@@ -0,0 +1,6 @@
+# Jacobian local state directory for artifact store and metadata.
+# Default: .jacobian (relative to working directory)
+JACOBIAN_STATE_DIR=.jacobian
+
+# Remote hosts should pass the token file and public URL as jacobian-mcp
+# arguments. Do not put bearer tokens in this environment file.

jacobian-0.2.0a0/.factory/droids/jacobian-dev.md

@@ -0,0 +1,60 @@
+---
+name: jacobian-dev
+description: >
+  Development agent for Jacobian's composable mathematical capability toolbox.
+  Use when implementing features, fixing bugs, or refactoring code
+  within the jacobian and jacobian_checkers packages.
+model: inherit
+---
+
+# Jacobian Development Droid
+
+You are a development agent for Jacobian, an MCP server, CLI, and Python
+library that exposes composable mathematical capabilities to AI agents.
+Jacobian supplies mathematical operations and trust boundaries; agents own
+the research strategy.
+
+## Core Principles
+
+1. **Fail-Closed Verification**: Never convert TIMEOUT, CANCELLED, ERROR, or
+   incomplete enumeration into a mathematical conclusion. Keep execution status,
+   input validity, mathematical conclusion, assurance, and evidence type separate.
+
+2. **Trust Boundaries**: Untrusted plugins and search code must not authorize
+   checkers or alter trust policy. Independent checkers must not depend on the
+   search implementation whose output they certify.
+
+3. **Mathematical Atomicity**: Each agent-visible capability should produce one
+   coherent mathematical outcome. Keep useful intermediate artifacts and proof
+   obligations visible instead of hiding them inside opaque workflows.
+
+4. **Agent-Owned Composition**: Put higher-level strategies in agent skills and
+   workflows. Capability recommendations are routing hints, not restrictions.
+
+5. **Domain Separation**: Domain plugins own mathematical schemas, transforms,
+   invariants, and witness meanings. The kernel owns artifact identity, execution
+   status, assurance, budgets, provenance, and checker authorization.
+
+## Development Workflow
+
+```sh
+make setup
+make test-fast
+make validate
+```
+
+## Package Structure
+
+- `src/jacobian/` -- Kernel, contracts, adapters, and domain capabilities
+- `src/jacobian_checkers/` -- Independent checkers for domain plugins
+- `tests/` -- pytest suite with contract, integration, property, and end_to_end tests
+- `docs/` -- Specifications, ADRs, architecture, and threat model
+- `benchmarks/` -- Agent evaluations and performance benchmarks
+
+## Key Constraints
+
+- Python 3.12+ only, typed with mypy strict mode
+- Ruff linting with extensive rule selection (A, B, C4, C90, E, F, I, N, PIE, PTH, RUF, SIM, TD, UP)
+- Coverage threshold: 50% minimum
+- All TODO comments must reference an issue: `TODO(#123): description`
+- Pre-commit hooks enforce formatting, syntax checks, and secret scanning

jacobian-0.2.0a0/.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,35 @@
+---
+name: Bug report
+about: Report a defect in the Jacobian kernel, checker, or CLI
+title: "[Bug]: "
+labels: ["bug"]
+assignees: []
+---
+
+**Priority**
+<!-- Select one: P0 (critical), P1 (high), P2 (medium), P3 (low) -->
+
+**Area**
+<!-- Which area is affected? kernel, checker, cli, mcp, docs, ci, deps, security -->
+
+**Component**
+<!-- Which part of Jacobian is affected? (e.g., artifact store, CLI, MCP adapter, checker, plugin) -->
+
+**Observed behavior**
+<!-- What happened? Include exact error messages or unexpected output. -->
+
+**Expected behavior**
+<!-- What should have happened instead? -->
+
+**Steps to reproduce**
+1.
+2.
+3.
+
+**Environment**
+- Jacobian version:
+- Python version:
+- OS:
+
+**Additional context**
+<!-- Screenshots, logs, or other relevant information. -->

jacobian-0.2.0a0/.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,28 @@
+---
+name: Feature request
+about: Propose or improve a mathematical capability
+title: "[Feature]: "
+labels: ["feature"]
+assignees: []
+---
+
+**Area**
+<!-- Which mathematical domain, capability family, adapter, or shared surface is affected? -->
+
+**Observed need**
+<!-- Which agent trace, evaluation, dataset, research case, or user workflow exposes the gap? -->
+
+**Mathematical outcome**
+<!-- What single agent-visible result should the capability produce? Include representative inputs and outputs when possible. -->
+
+**Existing tools and backends**
+<!-- Which current Jacobian capabilities, maintained libraries, proof assistants, CASs, solvers, or databases were considered? -->
+
+**Evidence and verification boundary**
+<!-- Is the result heuristic, approximate, bounded, exhaustive, exact, or independently checkable? What certificate or checker can verify it? -->
+
+**Evaluation**
+<!-- How would we tell whether this improves agent correctness, coverage, efficiency, or tool composition? Note any held-out cases or independent oracle. -->
+
+**Compatibility and additional context**
+<!-- Note public contract impact and link relevant issues, specifications, transcripts, benchmarks, or mathematical scenarios. -->

jacobian-0.2.0a0/.github/dependabot.yml

@@ -0,0 +1,17 @@
+version: 2
+updates:
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "09:00"
+      timezone: "UTC"
+    allow:
+      - dependency-type: "all"
+    labels:
+      - "dependencies"
+    commit-message:
+      prefix: "deps"
+      include: "scope"
+    open-pull-requests-limit: 5