ReeceandClaude Opus 4.7 62e772fd7a Fix review findings on form-fill branch post-merge
Critical:
- Remove orphaned delegate_form_fill ToolOutput from OrchestratorAgent;
  the method didn't exist and OrchestratorAgent(runtime) crashed at boot.
  Also drop unused DocumentExtractorAgent import and KnowledgeUpdateResponse
  from the OrchestratorResponse union. Form fill stays on its own endpoints
  (POST /api/v1/form/ai/*) and is not wired as an orchestrator delegate.

Medium:
- Thread conversation_history through the three form-fill agents.
  Contracts: FormAnalysisRequest, FormFillBatchRequest, and
  DocumentExtractionRequest now carry conversation_history. Agents call
  format_conversation_history() when building prompts, matching the
  pattern from PdfQuestionAgent / PdfEditAgent.
- Add input bounds to form-fill contracts (max_length on strings,
  min_length/max_length on lists and dicts). Caps: 50 files, 500 fields
  per file, 20 documents per request, 500 knowledge entries, 50k chars
  per document text, 8k chars per page text. Stops unbounded prompt growth.
- Replace Literal["fill_result"] / Literal["knowledge_update"] etc. with
  WorkflowOutcome enum values. Adds KNOWLEDGE_UPDATE, MULTI_PROFILE_EXTRACTION,
  and BATCH_FILL_RESULT to both WorkflowOutcome (Python) and
  AiWorkflowOutcome (Java) to keep the "must stay in sync" contract honest.

Low:
- Drop duplicate build_test_settings() helper in test_form_fill_agent.py;
  use conftest.build_app_settings() like the rest of the suite.
- Add test coverage for extract_multiple -> MultiProfileExtractionResponse
  (the two-person detection path).
- ARCHITECTURE.md: clarify where state actually lives
  (localStorage keys on the frontend, no user-scoping) and note that form
  fill is not an orchestrator delegate.

128 engine tests pass. Lifespan boots cleanly with all four agents.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 18:28:56 +01:00
2026-03-25 11:00:40 +00:00
2026-03-25 11:00:40 +00:00

Stirling PDF logo

Stirling PDF - The Open-Source PDF Platform

Stirling PDF is a powerful, open-source PDF editing platform. Run it as a personal desktop app, in the browser, or deploy it on your own servers with a private API. Edit, sign, redact, convert, and automate PDFs without sending documents to external services.

Docker Pulls Discord OpenSSF Scorecard GitHub Repo stars

Stirling PDF - Dashboard

Key Capabilities

  • Everywhere you work - Desktop client, browser UI, and self-hosted server with a private API.
  • 50+ PDF tools - Edit, merge, split, sign, redact, convert, OCR, compress, and more.
  • Automation & workflows - No-code pipelines direct in UI with APIs to process millions of PDFs.
  • Enterprise‑grade - SSO, auditing, and flexible on‑prem deployments.
  • Developer platform - REST APIs available for nearly all tools to integrate into your existing systems.
  • Global UI - Interface available in 40+ languages.

For a full feature list, see the docs: https://docs.stirlingpdf.com

Quick Start

docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf

Then open: http://localhost:8080

For full installation options (including desktop and Kubernetes), see our Documentation Guide.

Resources

Support

Contributing

We welcome contributions! Please see CONTRIBUTING.md for guidelines.

This project uses Task as a unified command runner for all build, dev, and test commands. Run task install to get started, or see the Developer Guide for full details.

For adding translations, see the Translation Guide.

License

Stirling PDF is open-core. See LICENSE for details.

Languages
Java 49.9%
TypeScript 39.9%
Python 4.3%
CSS 2.7%
Shell 0.9%
Other 2.2%