{ "schema_version": "forge.source-research-pack/v1", "cut_at": "2026-08-04T03:27:53Z", "methodology": { "mode": "zero-copy-human-synthesis", "raw_persisted": false, "semantic_groundedness": "human-reviewed-structural", "minimum_synthesis_supporting_sources": 2, "minimum_synthesis_groups": 2, "reviewed_by": "codex-SQ3", "limitations": "Receipts prove bounded acquisition and source binding. Source-description claims remain limited to the named publisher; synthesis claims require independent groups but remain design inputs, not product outcome or independent attestation." }, "researches": [ { "id": "R31-API-COVERAGE-CONTRACTS", "question": "How should FORGE 3.1 combine API descriptions, contract change detection, request tests and coverage without confusing their evidence boundaries?", "status": "reproducible", "method": "Compare versioned specification artifacts and official tool documentation, distinguish normative descriptions from implementation adapters, and require independent publishers for cross-tool synthesis.", "source_ids": [ "ASYNCAPI-3.1.0-README", "ASYNCAPI-3.1.0-SCHEMA", "OASDIFF-OPENAPI31", "OASDIFF-BREAKING-CHANGES", "RSWAG-2.17.0", "SIMPLECOV-1.0.3", "COVERAGEPY-7.15.3", "GITHUB-CODE-COVERAGE", "RSPEC-RAILS-REQUEST-SPECS", "RUBY-COVERAGE-4.0.6", "COBERTURA-2.1.1-DTD" ], "claims": [ { "id": "API31-C1", "kind": "synthesis", "statement": "A versioned API description, a compatibility diff and an executed request specification are separate evidence layers; FORGE should keep them distinct and bind each result to the same contract version.", "support": [ { "source_id": "ASYNCAPI-3.1.0-SCHEMA", "location_hint": "Versioned root schema and required top-level objects", "evidence_note": "The official schema makes the description contract structurally machine-verifiable for the pinned 3.1.0 cut.", "relation": "supports" }, { "source_id": "ASYNCAPI-3.1.0-README", "location_hint": "Specification purpose and message-driven API scope", "evidence_note": "AsyncAPI defines a machine-readable description surface for message-driven interfaces.", "relation": "supports" }, { "source_id": "OASDIFF-BREAKING-CHANGES", "location_hint": "Breaking changes catalog", "evidence_note": "oasdiff implements an explicit rule set for comparing versioned API descriptions.", "relation": "supports" }, { "source_id": "RSWAG-2.17.0", "location_hint": "Request specs, validation and OpenAPI generation", "evidence_note": "rswag executes request examples and derives or validates an API artifact from the test DSL.", "relation": "supports" } ], "confidence": "high", "limitations": "The selected positive intake covers official AsyncAPI 3.1.0 repository and schema artifacts, not the normative spec/asyncapi.md source of truth. OpenAPI 3.1.2 also remains a candidate not admitted by the v1 fetch policy, so this claim asserts neither AsyncAPI nor OpenAPI conformance." }, { "id": "API31-C2", "kind": "source-description", "statement": "oasdiff v1.27.0 documents OpenAPI 3.1 comparison and breaking-change rules; this is a useful CI control, not proof of semantic or business compatibility.", "support": [ { "source_id": "OASDIFF-OPENAPI31", "location_hint": "OpenAPI 3.1 support", "evidence_note": "The project documents its OpenAPI 3.1 comparison behavior and limitations.", "relation": "supports" }, { "source_id": "OASDIFF-BREAKING-CHANGES", "location_hint": "Breaking changes rules", "evidence_note": "The project enumerates the breaking changes detected by its rules.", "relation": "supports" } ], "confidence": "high", "limitations": "This claim describes oasdiff only. Rule coverage can lag a specification or miss domain invariants, and a green diff cannot certify business compatibility." }, { "id": "API31-C3", "kind": "source-description", "statement": "rswag 2.17.0 can execute RSpec request specs and generate or validate OpenAPI artifacts, while its consulted documentation demonstrates OpenAPI 3.0.x and JSON Schema Draft 4 behavior; it is therefore an optional Ruby adapter rather than FORGE authority for OpenAPI 3.1.", "support": [ { "source_id": "RSPEC-RAILS-REQUEST-SPECS", "location_hint": "Request spec execution examples", "evidence_note": "RSpec Rails documents request specs as executable application-level HTTP behavior checks.", "relation": "supports" }, { "source_id": "RSWAG-2.17.0", "location_hint": "README usage, OpenAPI output and schema validation", "evidence_note": "The release documentation joins request execution with generated API documentation and states its demonstrated schema behavior.", "relation": "supports" } ], "confidence": "high", "limitations": "The observation is version-specific. A product adopting rswag still needs a compatibility suite for its selected OpenAPI version and a runtime conformance gate." }, { "id": "API31-C4", "kind": "synthesis", "statement": "FORGE coverage evidence should be tool-neutral and normalize at least line, branch, scope, delta and threshold fields; SimpleCov and coverage.py remain language adapters, while an interchange report is not a quality verdict.", "support": [ { "source_id": "RUBY-COVERAGE-4.0.6", "location_hint": "Ruby Coverage runtime interface", "evidence_note": "Ruby exposes the runtime coverage primitive that language adapters such as SimpleCov consume.", "relation": "supports" }, { "source_id": "SIMPLECOV-1.0.3", "location_hint": "Coverage criteria, groups, filters and thresholds", "evidence_note": "SimpleCov exposes Ruby line and branch measurements plus thresholds and parallel result merging.", "relation": "supports" }, { "source_id": "COVERAGEPY-7.15.3", "location_hint": "XML report command", "evidence_note": "coverage.py emits an XML coverage report suitable for downstream ingestion.", "relation": "supports" }, { "source_id": "GITHUB-CODE-COVERAGE", "location_hint": "Supported languages and coverage report upload", "evidence_note": "GitHub documents ingestion across several languages through a common coverage-report workflow.", "relation": "supports" }, { "source_id": "COBERTURA-2.1.1-DTD", "location_hint": "Coverage XML DTD 0.4", "evidence_note": "The legacy Cobertura DTD provides a concrete XML interchange shape used by downstream consumers.", "relation": "qualifies" } ], "confidence": "high", "limitations": "The exact normalized FORGE schema remains a framework decision. Coverage percentage cannot prove test relevance, correctness, risk coverage or absence of defects." } ], "verdict": "Adopt contract-first, change-diff and runtime request evidence as separate controls; use rswag and SimpleCov only in the Ruby profile and keep public API and coverage contracts tool-neutral.", "limitations": "This research establishes design inputs and adapter boundaries. It does not prove that every product exposes an API, uses these tools, or already meets a shared threshold." }, { "id": "R31-MULTIPLAYER-HARNESS", "question": "Which multiplayer and long-running agent-harness ideas are mature enough to inform FORGE 3.1 without copying a vendor architecture or adding unmeasured complexity?", "status": "reproducible", "method": "Compare a pinned pre-1.0 multiplayer implementation with official empirical harness reports, separating directly described surfaces from cross-publisher design synthesis and retaining cost and maturity limits.", "source_ids": [ "QM-GETTING-STARTED", "QM-ADMIN", "QM-PORTAL", "QM-SLACK", "QM-WEB-UI", "QM-PACKAGE", "ANTHROPIC-HARNESS-DESIGN", "ANTHROPIC-MANAGED-AGENTS" ], "claims": [ { "id": "HARNESS31-C1", "kind": "source-description", "statement": "QM v0.1.4 exposes a multiplayer agent product through setup, admin, portal, Slack and web surfaces; FORGE can treat these as verified inspiration for scoped collaboration, not as a normative or production-maturity baseline.", "support": [ { "source_id": "QM-GETTING-STARTED", "location_hint": "Project setup and first-run workflow", "evidence_note": "The project documents a runnable setup rather than only a concept image.", "relation": "supports" }, { "source_id": "QM-ADMIN", "location_hint": "Admin plugin responsibilities", "evidence_note": "QM separates organization administration into an explicit plugin surface.", "relation": "supports" }, { "source_id": "QM-PORTAL", "location_hint": "Portal plugin responsibilities", "evidence_note": "QM exposes a portal boundary for shared access and application surfaces.", "relation": "supports" }, { "source_id": "QM-SLACK", "location_hint": "Slack integration architecture", "evidence_note": "QM implements Slack as an explicit channel integration.", "relation": "supports" }, { "source_id": "QM-WEB-UI", "location_hint": "Web UI plugin responsibilities", "evidence_note": "QM implements a separate web collaboration surface.", "relation": "supports" } ], "confidence": "high", "limitations": "The project is pre-1.0 and the selected public material provides no independent production reliability, security or adoption study." }, { "id": "HARNESS31-C2", "kind": "synthesis", "statement": "A durable harness should keep session history, orchestration policy and execution isolation as explicit boundaries, while adapters and plugins prevent model or channel choice from becoming the security boundary.", "support": [ { "source_id": "ANTHROPIC-MANAGED-AGENTS", "location_hint": "Session, harness and sandbox separation", "evidence_note": "The article describes stable interfaces between append-only session state, the harness loop and isolated execution.", "relation": "supports" }, { "source_id": "QM-PACKAGE", "location_hint": "Package and adapter metadata", "evidence_note": "The package surface exposes implementation adapters rather than a single hard-coded model client.", "relation": "supports" }, { "source_id": "QM-ADMIN", "location_hint": "Admin plugin boundary", "evidence_note": "Administrative policy is represented outside the conversational model surface.", "relation": "supports" } ], "confidence": "moderate", "limitations": "The sources show two implementations, not a neutral interoperability standard. Actual permissions must be independently enforced and tested outside model choice." }, { "id": "HARNESS31-C3", "kind": "source-description", "statement": "Anthropic reports that planner, generator and evaluator layers improved a long-running application result while materially increasing cost and latency; FORGE should require task-specific evals and ablation before making such layers mandatory.", "support": [ { "source_id": "ANTHROPIC-HARNESS-DESIGN", "location_hint": "Experiment architecture, results, cost and latency", "evidence_note": "The official experiment reports both the quality gain and the resource tradeoff of the layered harness.", "relation": "supports" } ], "confidence": "moderate", "limitations": "This is a provider experiment tied to a selected model, benchmark and application task; it cannot prove universal superiority of multi-agent or evaluator layers." }, { "id": "HARNESS31-C4", "kind": "synthesis", "statement": "Shared agent capabilities should be scoped and administered explicitly, while web, Slack and future channels remain replaceable integration surfaces rather than implicit organization-wide authority.", "support": [ { "source_id": "QM-ADMIN", "location_hint": "Administrative control surface", "evidence_note": "QM separates administration from end-user collaboration surfaces.", "relation": "supports" }, { "source_id": "QM-PORTAL", "location_hint": "Portal plugin surface", "evidence_note": "QM models a shared portal as an explicit integration component.", "relation": "supports" }, { "source_id": "QM-SLACK", "location_hint": "Slack integration surface", "evidence_note": "QM keeps Slack channel behavior in a named adapter boundary.", "relation": "supports" }, { "source_id": "ANTHROPIC-MANAGED-AGENTS", "location_hint": "Harness policy and sandbox interface", "evidence_note": "The article treats policy and execution boundaries as explicit harness responsibilities.", "relation": "supports" } ], "confidence": "moderate", "limitations": "The sources do not define a universal authorization model. FORGE still needs deny-by-default grants, tenant tests and revocation evidence before enforcement." } ], "verdict": "Adopt explicit scoped collaboration, durable handoff and replaceable adapters as design inputs; keep QM as verified inspiration and require eval, latency, cost and security evidence before adding mandatory orchestration layers.", "limitations": "No selected source establishes independent production maturity or proves that multiplayer operation improves every task. Product enforcement remains gated by HARNESS-IDENTITY and ARR v2 evidence." }, { "id": "R31-PUBLIC-KNOWLEDGE-DISCOVERY", "question": "What technical publication controls help people and search or AI systems discover FORGE knowledge without promising indexing, ranking or machine citation?", "status": "reproducible", "method": "Bind Google Search guidance to a versioned Schema.org vocabulary, keep publisher-specific behavior as source-description claims, and require independent support only for cross-vocabulary synthesis.", "source_ids": ["SCHEMAORG-30.0"], "claims": [ { "id": "SEO31-C2", "kind": "source-description", "statement": "Schema.org 30.0 provides a versioned shared vocabulary that can represent Article and BreadcrumbList metadata in JSON-LD; vocabulary use alone does not validate visible content or guarantee discovery features.", "support": [ { "source_id": "SCHEMAORG-30.0", "location_hint": "Versioned JSON-LD vocabulary", "evidence_note": "The pinned release contains the Article and BreadcrumbList terms in the shared Schema.org vocabulary.", "relation": "supports" } ], "confidence": "high", "limitations": "This claim describes the vocabulary only. It makes no claim about Google eligibility, ranking, rich-result display, AI citation or the truth of marked-up content." } ], "verdict": "Pin a shared vocabulary for deterministic structured-data validation, while keeping Google-specific canonical, sitemap, AI-search and crawler claims pending until an immutable official snapshot can pass trusted intake.", "limitations": "This positive cut validates the Schema.org vocabulary only. Dynamic Google documentation failed the immutable hash gate and is not projected as approved evidence." } ], "aggregate": { "source_count": 20, "independence_group_count": 12, "receipt_count": 20, "bytes_received": 2180694, "elapsed_ms": 8918, "http_calls": 20, "model_calls": 0, "model_tokens": 0, "cost_usd": 0, "research_count": 3, "claim_count": 9 } }