factoryline-code-factory 0.44.0__tar.gz → 0.44.2__tar.gz

{factoryline_code_factory-0.44.0 → factoryline_code_factory-0.44.2}/.zenodo.json

@@ -1,8 +1,8 @@
 {
   "title": "Code Factory: Proof-by-Sabotage Software Factory",
-  "description": "Code Factory catches AI-generated tests that could never fail and turns the result into local, reviewable evidence through Unified Graph Ops, including Mermaid diagrams for bounded proof paths. Existing assurance includes LangGraph resume parity and the Gauntlet Survival Card. Version 0.44.0 adds First Proof: one command runs a sealed sandbox demonstration, confirms a healthy positive control, catches an intentionally hollow negative control as HOLLOW_E2E_TEST, and writes a privacy-safe Proof Card. Local opt-in adoption milestones make activation measurable without transmitting identity or mistaking downloads for users. The release also starts a 21-day adoption sprint and a voluntary ten-repository Proof Clinic. Release media retains the current FactoryLine identity asset and real product captures.\n\nEvidence boundary: First Proof is a demonstration, not an assessment of the user's project. Proof Cards summarize one verified receipt and exclude commands, paths, repository names, prompts, logs, and identity. They do not certify production readiness, security, coverage, identity, or release authority.\n\nDual licensed under MIT or Apache-2.0.",
-  "version": "0.44.0",
-  "publication_date": "2026-08-21",
+  "description": "Code Factory catches AI-generated tests that could never fail and turns the result into local, reviewable evidence through Unified Graph Ops, including Mermaid diagrams for bounded proof paths. Existing assurance includes LangGraph resume parity and the Gauntlet Survival Card. Version 0.44.2 adds read-only intent-lineage navigation: a verified adapter shows the exact Forge ship source and line and lets a reviewer focus that node without granting authority. The 60-day personal-use case remains illustrative and is not a benchmark, guaranteed ROI, or verified cash saving; net savings must subtract tool cost and human oversight.\n\nEvidence boundary: First Proof is a demonstration, not an assessment of the user's project. Proof Cards summarize one verified receipt and exclude commands, paths, repository names, prompts, logs, and identity. They do not certify production readiness, security, coverage, identity, or release authority.\n\nCase-study visual: https://raw.githubusercontent.com/zrk222/code-factory/v0.44.2/docs/assets/marketplace/code-factory-60-day-personal-case-study.png\n\nDual licensed under MIT or Apache-2.0.",
+  "version": "0.44.2",
+  "publication_date": "2026-08-24",
   "creators": [
     {
       "name": "Katz, Richard"

{factoryline_code_factory-0.44.0 → factoryline_code_factory-0.44.2}/CITATION.cff

@@ -7,5 +7,5 @@ authors:
     given-names: Richard
 repository-code: "https://github.com/zrk222/code-factory"
 license: "MIT OR Apache-2.0"
-version: 0.44.0
+version: 0.44.2
 date-released: 2026-08-21

{factoryline_code_factory-0.44.0 → factoryline_code_factory-0.44.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: factoryline-code-factory
-Version: 0.44.0
+Version: 0.44.2
 Summary: Catch AI-generated tests that could never fail and review AI code with local proof.
 Author: Richard Katz
 Author-email: rkatz22@gmail.com
@@ -79,10 +79,16 @@ are ready to build, run `factory mvp "Build an approval tracker" --root .`.
 
 ![Actual privacy-safe First Proof Card: the hollow test was detected](docs/assets/first-proof-card.svg)
 
-[See actual Factory Studio](docs/PRODUCT_VISUALS.md) or open the
+[See actual Factory Studio and the current FactoryLine visual set](docs/PRODUCT_VISUALS.md) or open the
 [live Hugging Face Space](https://zrk222-code-factory.static.hf.space).
 
-![Actual Factory Studio: the outcome-first local MVP path](docs/assets/marketplace/factory-studio-mvp-1280x800.png)
+![Actual FactoryLine 0.44 Graph Ops dashboard showing a waiting-for-human assembly, live telemetry, and evidence-backed next actions](docs/assets/marketplace/factoryline-0.44-live-dashboard.png)
+
+![FactoryLine AI Proof controls in IntelliJ IDEA for first proof, assemblies, receipts, changed-proof analysis, Change Lists, workspace analysis, and the local meter](docs/assets/marketplace/factoryline-jetbrains-0.44-all-controls.jpg)
+
+![FactoryLine AI Proof running a successful local First Proof on FactoryLine 0.44 inside IntelliJ IDEA](docs/assets/marketplace/factoryline-jetbrains-0.44-in-action.jpg)
+
+![Actual Factory Studio showing the outcome-first local MVP path and local-only boundary](docs/assets/marketplace/factory-studio-mvp-1280x800.png)
 
 ## What it does
 
@@ -137,6 +143,65 @@ are ready to build, run `factory mvp "Build an approval tracker" --root .`.
 These are local evidence and supervision tools, not guarantees of performance,
 security, productivity, production readiness, or an automatic repair service.
 
+## FactoryLine by role
+
+| Who is using it | Start here | Highest-value uses | The result they can inspect |
+| --- | --- | --- | --- |
+| **Novice / first-time builder** | `factory first-proof`, then `factory mvp` | Catch a test that only looks green; turn one outcome into a contained starter; learn the difference between generated code and proven behavior | A privacy-safe Proof Card, a local MVP, and a visible next step instead of an unexplained pass/fail |
+| **Junior developer** | `factory prd grill`, `factory plan verify`, `factory change review` | Clarify acceptance evidence before coding; keep an AI-assisted diff inside the approved plan; surface missing tests and Proof Debt before review | Source-bound questions, exact changed paths, severity-ordered findings, and a review handoff |
+| **Senior / staff engineer** | `factory judgment`, `factory graph forensics`, `factory proofsearch`, `factory gauntlet` | Protect architecture decisions; diagnose resumed or parallel workflow drift; compare candidate repairs; challenge whether critical E2E checks can actually reject declared failures | Hash-bound decision context, first-divergence facts, rejected candidates, a deterministic winner, and Survival Cards |
+| **Engineering team** | `factory wrap`, GitHub Proof Review, Graph Ops, Agent License and Combine | Put agent work into one evidence ledger; add a neutral PR Check beside AI review; hand off proof state; compare sealed runs without turning scores into vendor claims | Commit-bound Checks, local receipts, explicit owners and blockers, proof reuse decisions, and comparable governed-run records |
+| **Enterprise / platform team** | Intake Grill, Verifier Plane, policy challenge, assurance dossier, admission controls | Standardize approval boundaries; test whether policy rules matter; keep signers, exceptions, tenants, budgets, and release evidence explicit; integrate with existing SDLC controls | Independently verifiable packets and read-only operational views; identity, credentials, merge, release, and deployment remain in enterprise-owned systems |
+
+## Expected operational outcomes
+
+FactoryLine is designed to reduce avoidable review loops, evidence hunting, and
+the frustration of discovering late that an AI-generated test never exercised
+the claimed behavior. The expected outcome is a shorter path to a defensible
+human decision—not a promise that every project becomes faster or cheaper.
+
+| Outcome | What should improve | Evidence FactoryLine can retain |
+| --- | --- | --- |
+| **Less time lost before coding** | Ambiguous intent, missing acceptance evidence, and external-effect boundaries surface during intake instead of after implementation | Intake questions, approved scope, plan hashes, and explicit blockers |
+| **Faster review orientation** | Reviewers receive the exact diff, proof state, top risk, and one supported next action instead of reconstructing context across chat logs | Proof Cards, Change Review, Plan-to-Proof findings, GitHub Checks, and handoff packets |
+| **Less frustrating rework** | Hollow validators, duplicate effects, resume drift, and out-of-plan changes are challenged closer to their source | Negative-test results, first-divergence facts, rejected candidates, and Proof Debt |
+| **Lower evidence-handling cost** | Reusable receipts and read-only dashboards reduce repeated screenshots, manual summaries, and status meetings | Receipt reuse decisions, governed-run records, assurance dossiers, and local Graph Ops views |
+| **Measurable savings when a baseline exists** | Teams can compare observed duration or cost with a declared baseline; otherwise savings stay unavailable | Bounded savings records that label source, baseline, observation window, and confidence |
+
+FactoryLine never converts an unmeasured estimate into a savings claim. Use the
+[Savings Tracker](docs/SAVINGS_TRACKER.md) to report observed time or cost only
+when the repository has a valid baseline and evidence window.
+
+For planning, a transparent starting band is **25–120 minutes of avoidable
+review and rework per AI-assisted PR**: roughly 10–30 minutes of reviewer
+context reconstruction plus 15–90 minutes of one preventable clarification,
+validator, or scope-rework loop. At 50 AI-assisted PRs per month, that models
+about **21–100 hours**; at a team-supplied loaded cost of $75–$150/hour, the
+illustrative range is about **$1,560–$15,000 per month**. These are adjustable
+scenario inputs, not observed FactoryLine results. See the
+[outcomes and savings model](docs/OUTCOMES_MODEL.md) before using the range.
+
+![Code Factory 60-day personal case study: observed local Codex metadata and a clearly separated modeled capacity range](docs/assets/marketplace/code-factory-60-day-personal-case-study.png)
+
+## Works with your existing AI development stack
+
+FactoryLine is the proof and control layer around generation, orchestration, and
+review tools. The status column distinguishes implemented adapters from clean
+workflow fits; it does not imply a vendor partnership.
+
+| Product or stack | What it does well | Where FactoryLine adds value | Current connection status |
+| --- | --- | --- | --- |
+| **Blitzy** | Large codebase understanding, reviewed action plans, autonomous generation, validation, and PR creation | Seal the approved plan, compare it with the exact resulting diff, challenge declared tests, and attach a neutral proof walkthrough before human merge | **Workflow fit.** Use repository artifacts and PR Checks; no bundled Blitzy API adapter or claimed partnership |
+| **CodeRabbit** | AI review comments and remediation suggestions across the pull request | Supply deterministic FactoryLine Check results, proof gaps, and Proof Debt beside the AI review without treating suggestions as evidence | **Documented interoperability.** GitHub Checks are the boundary; no CodeRabbit credential or API is required |
+| **Mastra** | TypeScript agents, tools, memory, workflows, and MCP clients/servers | Expose read-only local proof context through MCP, then verify the resulting repository diff and declared tests independently | **Protocol-level fit.** Mastra supports MCP; a dedicated FactoryLine-Mastra adapter is not bundled or claimed tested |
+| **LangGraph** | Durable, stateful agent orchestration with checkpoints and human-in-the-loop control | Compare sealed reference and resumed transition lineages, detect duplicate effects or unsafe parallel writes, and keep receipts authoritative over checkpoints | **Native optional support.** LangGraph Assurance Bridge, optional adapter, GitHub Action, and cross-agent plugin are included |
+| **Codex, Claude Code, and Deep Agents** | Interactive or autonomous repository implementation | Admit scoped work, wrap the local CLI process, hash the file delta, run independent validators, and feed Agent License / Combine | **Included paths.** Local wrapper, read-only MCP, LangGraph plugin, and optional Claude session trace |
+| **Cursor and OpenCode** | IDE- or terminal-based AI coding with MCP clients | Read bounded FactoryLine receipt, verifier, PRD, memory-brief, and Graph Ops facts without granting write or release authority | **Documented local MCP setup.** Stdio-only and read-only |
+| **DeepSeek Harness** | Model session and tool lifecycle | Add FactoryLine’s local proof facts while keeping the harness responsible for the agent lifecycle | **Opt-in adapter.** Developer-preview upstream boundary is explicit |
+
+See the [complete compatibility and handoff guide](docs/WORKS_WITH.md) for the
+recommended flow and the exact authority boundary for each stack.
+
 **For teams:** use the [Teams and Enterprise Operations Manual](docs/ENTERPRISE_TEAMS_OPERATIONS.md)
 to run the same proof-first loop with named reviewers, approved AI-change scope,
 and explicit Proof Debt—without giving Code Factory merge, release, or provider authority.
@@ -273,6 +338,13 @@ the same future price. It is for maintained, customer-managed proof operations
 packets)—not source access or opaque AI-token resale. The source license and free
 core are unchanged. See the [GitHub per-seat plan](docs/GITHUB_MONETIZATION_2026.md).
 
+For Open VSX, the extension and local proof core remain free. All capabilities
+shipped before the transition are free through **December 14, 2026**. From
+**December 15, 2026**, optional hosted Personal Memory is scheduled at **$4.95
+USD/month**, and Team Assurance at **$5.95 USD per named seat/month** or **$60
+USD per named seat/year**, subject to explicit activation gates. See the
+[Open VSX service plan](docs/OPEN_VSX_MONETIZATION_2026.md).
+
 ## The proof boundary
 
 Code Factory creates and inspects local artifacts. It does **not** silently call a
@@ -314,7 +386,7 @@ context reusable by a client you choose.
   optional design-quality lane and its explicit review boundaries.
 - Read [The approval signal decays when AI-written code becomes routine](docs/HABITUATION_ESSAY.md)
   for the design and limits of the habituation gate.
-- See the [release notes](docs/RELEASE_NOTES_0.44.0.md),
+- See the [release notes](docs/RELEASE_NOTES_0.44.2.md),
   [CHANGELOG.md](CHANGELOG.md), [release channels](docs/RELEASE_CHANNELS.md), and
   [publication guide](PUBLICATION_GUIDE.md) for versioned release detail.
 

{factoryline_code_factory-0.44.0 → factoryline_code_factory-0.44.2}/README.md

@@ -30,10 +30,16 @@ are ready to build, run `factory mvp "Build an approval tracker" --root .`.
 
 ![Actual privacy-safe First Proof Card: the hollow test was detected](docs/assets/first-proof-card.svg)
 
-[See actual Factory Studio](docs/PRODUCT_VISUALS.md) or open the
+[See actual Factory Studio and the current FactoryLine visual set](docs/PRODUCT_VISUALS.md) or open the
 [live Hugging Face Space](https://zrk222-code-factory.static.hf.space).
 
-![Actual Factory Studio: the outcome-first local MVP path](docs/assets/marketplace/factory-studio-mvp-1280x800.png)
+![Actual FactoryLine 0.44 Graph Ops dashboard showing a waiting-for-human assembly, live telemetry, and evidence-backed next actions](docs/assets/marketplace/factoryline-0.44-live-dashboard.png)
+
+![FactoryLine AI Proof controls in IntelliJ IDEA for first proof, assemblies, receipts, changed-proof analysis, Change Lists, workspace analysis, and the local meter](docs/assets/marketplace/factoryline-jetbrains-0.44-all-controls.jpg)
+
+![FactoryLine AI Proof running a successful local First Proof on FactoryLine 0.44 inside IntelliJ IDEA](docs/assets/marketplace/factoryline-jetbrains-0.44-in-action.jpg)
+
+![Actual Factory Studio showing the outcome-first local MVP path and local-only boundary](docs/assets/marketplace/factory-studio-mvp-1280x800.png)
 
 ## What it does
 
@@ -88,6 +94,65 @@ are ready to build, run `factory mvp "Build an approval tracker" --root .`.
 These are local evidence and supervision tools, not guarantees of performance,
 security, productivity, production readiness, or an automatic repair service.
 
+## FactoryLine by role
+
+| Who is using it | Start here | Highest-value uses | The result they can inspect |
+| --- | --- | --- | --- |
+| **Novice / first-time builder** | `factory first-proof`, then `factory mvp` | Catch a test that only looks green; turn one outcome into a contained starter; learn the difference between generated code and proven behavior | A privacy-safe Proof Card, a local MVP, and a visible next step instead of an unexplained pass/fail |
+| **Junior developer** | `factory prd grill`, `factory plan verify`, `factory change review` | Clarify acceptance evidence before coding; keep an AI-assisted diff inside the approved plan; surface missing tests and Proof Debt before review | Source-bound questions, exact changed paths, severity-ordered findings, and a review handoff |
+| **Senior / staff engineer** | `factory judgment`, `factory graph forensics`, `factory proofsearch`, `factory gauntlet` | Protect architecture decisions; diagnose resumed or parallel workflow drift; compare candidate repairs; challenge whether critical E2E checks can actually reject declared failures | Hash-bound decision context, first-divergence facts, rejected candidates, a deterministic winner, and Survival Cards |
+| **Engineering team** | `factory wrap`, GitHub Proof Review, Graph Ops, Agent License and Combine | Put agent work into one evidence ledger; add a neutral PR Check beside AI review; hand off proof state; compare sealed runs without turning scores into vendor claims | Commit-bound Checks, local receipts, explicit owners and blockers, proof reuse decisions, and comparable governed-run records |
+| **Enterprise / platform team** | Intake Grill, Verifier Plane, policy challenge, assurance dossier, admission controls | Standardize approval boundaries; test whether policy rules matter; keep signers, exceptions, tenants, budgets, and release evidence explicit; integrate with existing SDLC controls | Independently verifiable packets and read-only operational views; identity, credentials, merge, release, and deployment remain in enterprise-owned systems |
+
+## Expected operational outcomes
+
+FactoryLine is designed to reduce avoidable review loops, evidence hunting, and
+the frustration of discovering late that an AI-generated test never exercised
+the claimed behavior. The expected outcome is a shorter path to a defensible
+human decision—not a promise that every project becomes faster or cheaper.
+
+| Outcome | What should improve | Evidence FactoryLine can retain |
+| --- | --- | --- |
+| **Less time lost before coding** | Ambiguous intent, missing acceptance evidence, and external-effect boundaries surface during intake instead of after implementation | Intake questions, approved scope, plan hashes, and explicit blockers |
+| **Faster review orientation** | Reviewers receive the exact diff, proof state, top risk, and one supported next action instead of reconstructing context across chat logs | Proof Cards, Change Review, Plan-to-Proof findings, GitHub Checks, and handoff packets |
+| **Less frustrating rework** | Hollow validators, duplicate effects, resume drift, and out-of-plan changes are challenged closer to their source | Negative-test results, first-divergence facts, rejected candidates, and Proof Debt |
+| **Lower evidence-handling cost** | Reusable receipts and read-only dashboards reduce repeated screenshots, manual summaries, and status meetings | Receipt reuse decisions, governed-run records, assurance dossiers, and local Graph Ops views |
+| **Measurable savings when a baseline exists** | Teams can compare observed duration or cost with a declared baseline; otherwise savings stay unavailable | Bounded savings records that label source, baseline, observation window, and confidence |
+
+FactoryLine never converts an unmeasured estimate into a savings claim. Use the
+[Savings Tracker](docs/SAVINGS_TRACKER.md) to report observed time or cost only
+when the repository has a valid baseline and evidence window.
+
+For planning, a transparent starting band is **25–120 minutes of avoidable
+review and rework per AI-assisted PR**: roughly 10–30 minutes of reviewer
+context reconstruction plus 15–90 minutes of one preventable clarification,
+validator, or scope-rework loop. At 50 AI-assisted PRs per month, that models
+about **21–100 hours**; at a team-supplied loaded cost of $75–$150/hour, the
+illustrative range is about **$1,560–$15,000 per month**. These are adjustable
+scenario inputs, not observed FactoryLine results. See the
+[outcomes and savings model](docs/OUTCOMES_MODEL.md) before using the range.
+
+![Code Factory 60-day personal case study: observed local Codex metadata and a clearly separated modeled capacity range](docs/assets/marketplace/code-factory-60-day-personal-case-study.png)
+
+## Works with your existing AI development stack
+
+FactoryLine is the proof and control layer around generation, orchestration, and
+review tools. The status column distinguishes implemented adapters from clean
+workflow fits; it does not imply a vendor partnership.
+
+| Product or stack | What it does well | Where FactoryLine adds value | Current connection status |
+| --- | --- | --- | --- |
+| **Blitzy** | Large codebase understanding, reviewed action plans, autonomous generation, validation, and PR creation | Seal the approved plan, compare it with the exact resulting diff, challenge declared tests, and attach a neutral proof walkthrough before human merge | **Workflow fit.** Use repository artifacts and PR Checks; no bundled Blitzy API adapter or claimed partnership |
+| **CodeRabbit** | AI review comments and remediation suggestions across the pull request | Supply deterministic FactoryLine Check results, proof gaps, and Proof Debt beside the AI review without treating suggestions as evidence | **Documented interoperability.** GitHub Checks are the boundary; no CodeRabbit credential or API is required |
+| **Mastra** | TypeScript agents, tools, memory, workflows, and MCP clients/servers | Expose read-only local proof context through MCP, then verify the resulting repository diff and declared tests independently | **Protocol-level fit.** Mastra supports MCP; a dedicated FactoryLine-Mastra adapter is not bundled or claimed tested |
+| **LangGraph** | Durable, stateful agent orchestration with checkpoints and human-in-the-loop control | Compare sealed reference and resumed transition lineages, detect duplicate effects or unsafe parallel writes, and keep receipts authoritative over checkpoints | **Native optional support.** LangGraph Assurance Bridge, optional adapter, GitHub Action, and cross-agent plugin are included |
+| **Codex, Claude Code, and Deep Agents** | Interactive or autonomous repository implementation | Admit scoped work, wrap the local CLI process, hash the file delta, run independent validators, and feed Agent License / Combine | **Included paths.** Local wrapper, read-only MCP, LangGraph plugin, and optional Claude session trace |
+| **Cursor and OpenCode** | IDE- or terminal-based AI coding with MCP clients | Read bounded FactoryLine receipt, verifier, PRD, memory-brief, and Graph Ops facts without granting write or release authority | **Documented local MCP setup.** Stdio-only and read-only |
+| **DeepSeek Harness** | Model session and tool lifecycle | Add FactoryLine’s local proof facts while keeping the harness responsible for the agent lifecycle | **Opt-in adapter.** Developer-preview upstream boundary is explicit |
+
+See the [complete compatibility and handoff guide](docs/WORKS_WITH.md) for the
+recommended flow and the exact authority boundary for each stack.
+
 **For teams:** use the [Teams and Enterprise Operations Manual](docs/ENTERPRISE_TEAMS_OPERATIONS.md)
 to run the same proof-first loop with named reviewers, approved AI-change scope,
 and explicit Proof Debt—without giving Code Factory merge, release, or provider authority.
@@ -224,6 +289,13 @@ the same future price. It is for maintained, customer-managed proof operations
 packets)—not source access or opaque AI-token resale. The source license and free
 core are unchanged. See the [GitHub per-seat plan](docs/GITHUB_MONETIZATION_2026.md).
 
+For Open VSX, the extension and local proof core remain free. All capabilities
+shipped before the transition are free through **December 14, 2026**. From
+**December 15, 2026**, optional hosted Personal Memory is scheduled at **$4.95
+USD/month**, and Team Assurance at **$5.95 USD per named seat/month** or **$60
+USD per named seat/year**, subject to explicit activation gates. See the
+[Open VSX service plan](docs/OPEN_VSX_MONETIZATION_2026.md).
+
 ## The proof boundary
 
 Code Factory creates and inspects local artifacts. It does **not** silently call a
@@ -265,7 +337,7 @@ context reusable by a client you choose.
   optional design-quality lane and its explicit review boundaries.
 - Read [The approval signal decays when AI-written code becomes routine](docs/HABITUATION_ESSAY.md)
   for the design and limits of the habituation gate.
-- See the [release notes](docs/RELEASE_NOTES_0.44.0.md),
+- See the [release notes](docs/RELEASE_NOTES_0.44.2.md),
   [CHANGELOG.md](CHANGELOG.md), [release channels](docs/RELEASE_CHANNELS.md), and
   [publication guide](PUBLICATION_GUIDE.md) for versioned release detail.
 

factoryline_code_factory-0.44.2/docs/AGENT_ECONOMY_RESEARCH_2026.md

@@ -0,0 +1,103 @@
+# Agent Oven and the 2026 agent economy
+
+Research date: 2026-08-24. Sources are current official protocol, platform, payment-network, and marketplace documentation. This is product architecture research, not legal, tax, payments, or securities advice.
+
+## The opening
+
+The emerging stack is becoming modular:
+
+1. **MCP** connects an agent to tools and data. Its current authorization guidance requires audience-bound tokens and forbids token passthrough.
+2. **A2A** lets agents publish Agent Cards and collaborate through task lifecycles.
+3. **AP2** carries typed intent and payment mandates so machine spending can remain bound to human-approved limits.
+4. **MPP and x402** let machines pay HTTP services programmatically.
+5. **Agent marketplaces** make prebuilt agents discoverable, purchasable, and deployable.
+
+These layers describe who can call whom, what can be bought, and how value can move. They do not independently prove that a purchased agent delivered the promised business result. Agent Oven should own that missing layer: an immutable outcome contract, exact proof obligations, an independent deterministic verdict, and conditional release of an authorized result price.
+
+## Official evidence
+
+- [A2A specification](https://a2a-protocol.org/latest/) defines Agent Cards and agent-to-agent task interoperability.
+- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28/) moves the core to stateless HTTP, adds routable headers and cacheable catalogs, and hardens authorization.
+- [MCP authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) requires protected-resource discovery, token audience validation, PKCE, and no token passthrough.
+- [Google's agent protocol guide](https://developers.googleblog.com/en/developers-guide-to-ai-agent-protocols/) distinguishes MCP, A2A, commerce, and AP2 payment mandates.
+- [Stripe MPP](https://stripe.com/blog/machine-payments-protocol) enables agents to pay HTTP, API, and MCP services through machine-native payment requests.
+- [x402 documentation](https://docs.x402.org/introduction) uses HTTP 402 for accountless programmatic payment and supports machine-to-machine usage.
+- [Stripe Connect marketplace charges](https://docs.stripe.com/connect/charges) documents destination charges and separate charges/transfers, including the platform's refund and dispute responsibilities.
+- [Microsoft Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/) provides agent identities, sponsors, lifecycle governance, and conditional access.
+- [AWS Marketplace AI agents](https://aws.amazon.com/marketplace/solutions/ai-agents-and-tools) offers prebuilt agents, tools, deployment, procurement, and usage/contract pricing.
+- [Salesforce AgentExchange](https://www.salesforce.com/news/press-releases/2025/03/04/agentexchange-announcement/) offers prebuilt actions, topics, and templates inside Agentforce.
+- [Visa Intelligent Commerce](https://www.visa.com/en-us/solutions/intelligent-commerce) emphasizes agent credentials, spend controls, authentication, and consumer visibility.
+- [Google UCP](https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/) standardizes agent commerce and is designed to work through API, A2A, and MCP surfaces with AP2-compatible payment authorization.
+
+## Product conclusions
+
+### 1. Sell a result contract, not an agent-shaped subscription
+
+Every offer needs a deliverable, acceptance checklist, evidence format, price, expiry, authority boundary, and dispute route. Vague promises such as "improve support" are not payable outcomes. A bounded offer such as "produce a source-linked triage packet for one ticket and pass the four stated checks" can be verified.
+
+### 2. Build for two buyers
+
+- Humans need plain-language outcomes, transparent prices, confirmation, supervision, and a dispute/cancel control.
+- Agents need deterministic discovery, JSON schemas, idempotency, mandates, bounded delegation, status reads, and receipts.
+
+Both surfaces must operate the same server-owned contract rather than diverging into a human UI and an ungoverned machine back door.
+
+### 3. Outcome verification is the moat
+
+The seller cannot grade its own work. An exact required-check set, hash-bound artifacts, an independent reviewer identity, and fail-closed state transitions are more defensible than a generic LLM score. Model critique may explain a result, but it cannot release payment.
+
+### 4. Start with internal credits; activate money only through a real rail
+
+The product can prove result pricing today using atomic platform-credit reservations. Real-money activation requires provider onboarding, KYC/KYB, tax and payout decisions, refund/dispute handling, webhook verification, regional availability, and legal terms. Internal reservations must not be marketed as escrow.
+
+### 5. Prebuilt agents must have low-ambiguity outcomes
+
+The first six offers target artifacts that can be inspected without giving the agent unilateral consequential authority:
+
+1. PR Evidence Auditor - verified pull-request proof packet.
+2. Security Questionnaire Agent - source-linked response packet for human approval.
+3. Support Resolution Agent - policy-grounded response and resolution evidence, not autonomous refunds.
+4. Data Quality Reconciler - accepted discrepancy and remediation packet, not silent database writes.
+5. Invoice Exception Triage - categorized exception packet, not payment execution.
+6. Compliance Evidence Monitor - source-linked change/gap packet, not a compliance certification.
+
+### 6. Non-negotiable controls
+
+- authenticated agent identity with a human sponsor;
+- exact resource audience and no token passthrough;
+- idempotency and replay resistance;
+- one-hop delegation limit and separate sub-budget;
+- short expiry and kill switch;
+- immutable price, authority, and proof obligations after hire;
+- evidence quarantine and prompt-injection treatment for untrusted artifacts;
+- deterministic payout gate and independent reviewer;
+- explicit `setup-required` status for unverified external rails.
+
+## Commercial path
+
+- **Now:** free catalog discovery and sandbox/internal-credit result contracts.
+- **Pilot:** platform fee on verified results, after one regulated payment provider is integrated and audited.
+- **Teams:** private offer catalogs, approved-agent allowlists, pooled budgets, SSO/SCIM, audit export, and SLA controls.
+- **Enterprise:** private deployment, identity-provider agent sponsorship, policy packs, regional controls, dispute operations, and signed evidence retention.
+
+No revenue, savings, success-rate, or adoption claim should be published until Agent Oven has provider and customer receipts.
+
+## Runtime cooperation: LangGraph and Mastra
+
+The runtime market does not require Agent Oven to pick a single framework:
+
+- LangGraph's current Graph and Functional APIs emphasize explicit or code-shaped control flow, checkpoint persistence, interrupts, retries, replay, and durable human-in-the-loop execution. These are the right primitives for long-running or state-sensitive jobs.
+- Mastra's current product emphasizes TypeScript agents, typed tools, workflows, workspaces and sandboxes, MCP exposure, versioned editing, and a governed Agent Builder. These are strong primitives for JavaScript teams and integration-heavy internal agents.
+- Both frameworks already build and execute capable agents. Agent Oven's differentiator is the portable intent, policy, evidence, budget, independent-verification, and result-settlement layer around them.
+
+The resulting UX is a form-agent hybrid: one plain-language brief, visible missing questions, a recommended or explicit runtime, a graph preview, model access choice (managed route or BYOK), and a proof contract. A save produces a draft; adapter validation and human activation remain mandatory.
+
+Primary sources:
+
+- https://docs.langchain.com/oss/javascript/langgraph/workflows-agents
+- https://docs.langchain.com/oss/javascript/langgraph/persistence
+- https://docs.langchain.com/oss/javascript/langgraph/functional-api
+- https://mastra.ai/blog/announcing-agent-builder
+- https://mastra.ai/docs/agents/mcp-guide
+- https://mastra.ai/blog/introducing-mastra-workspaces
+- https://mastra.ai/en/reference/workflows/snapshots

{factoryline_code_factory-0.44.0 → factoryline_code_factory-0.44.2}/docs/AI_CLIENTS.md

@@ -11,7 +11,7 @@ Install the published package in the same environment that the client can
 launch, then verify the workspace boundary:
 
 ```powershell
-python -m pip install factoryline-code-factory==0.44.0
+python -m pip install factoryline-code-factory==0.44.2
 factory mcp status --root C:\work\my-mvp --json
 factory mcp config --client generic --root C:\work\my-mvp --json
 ```

factoryline_code_factory-0.44.2/docs/AUTHORITATIVE_SOURCE_CONTROL.md

@@ -0,0 +1,78 @@
+# Agent Oven Authoritative Source Control
+
+## Outcome
+
+Agent Oven now separates ordinary retrieval context from sources that can justify a regulated run. The control plane will refuse new execution when a required authority group has too few current official or licensed sources, or when none of those sources is healthy.
+
+This is a fail-closed availability control. It does not promise that a government, regulator, registry, or licensed vendor will remain online.
+
+## Authority classes
+
+| Class | Counts toward run readiness | Intended use |
+|---|---:|---|
+| `primary-law` | Yes | Statutes, regulations, gazettes, filed rules |
+| `official-regulator` | Yes | Regulator guidance, bulletins, enforcement notices |
+| `official-registry` | Yes | Licences, titles, permits, professional status |
+| `licensed-system-of-record` | Yes | Contracted authoritative datasets and transactional systems |
+| `secondary-corroboration` | No | Discovery, commentary, summaries, cross-checks |
+
+Secondary sources remain visible, but never substitute for authority.
+
+## Readiness rules
+
+Each source declares a freshness SLO, maximum age, current consecutive failure count, and redundancy group. Evaluation uses one server timestamp for the entire enqueue decision.
+
+- `healthy`: latest success is inside the freshness SLO and there are no consecutive failures.
+- `degraded`: latest success is still inside maximum age, but freshness is outside SLO or one to two checks failed.
+- `stale`: latest success is older than maximum age.
+- `unavailable`: no successful worker observation exists, or three consecutive checks failed.
+- `setup-required`: metadata exists but a trusted worker has not activated it.
+- `disabled`: an admin has deliberately removed it from service.
+
+A required group is ready only when:
+
+1. its declared minimum number of non-secondary sources are healthy or degraded; and
+2. at least one qualifying source is healthy.
+
+Otherwise the exact blocker is `AUTHORITATIVE_COUNT_BELOW_MINIMUM` or `NO_HEALTHY_AUTHORITATIVE_SOURCE`.
+
+## Trusted-worker boundary
+
+Convex stores source metadata, opaque `env:` or `vault:` references, configuration digests, and bounded observations. It stores no raw credential, response body, protected record, or licensed dataset content. External fetching belongs to a separately deployed trusted worker.
+
+Workers call the internal `authoritativeSources.recordObservation` mutation with:
+
+- a unique 1–160-character observation key;
+- `success` or `failure`;
+- observation time and 0–300,000 ms latency;
+- optional source-published time and content digest;
+- a closed failure code for failures.
+
+Replaying the same source and observation key returns the existing observation without incrementing failure counters.
+
+The deployable worker library in `runtime/sourceWorker.ts` now supplies the bounded I/O contract: HTTPS-only resolved endpoints, 10-second attempt timeout, at most three attempts for timeout/429/5xx failures, 250 ms then 1000 ms backoff, a 2 MiB body ceiling, SHA-256-only output, and batches of at most five concurrent probes. An authenticated operator worker obtains credential-free definitions from `listWorkerDefinitions` and submits a digest-pinned result through `recordWorkerObservation`; configuration drift fails before source state changes.
+
+The library is now packaged as a scheduled service with liveness/readiness endpoints, metadata-only alert retry, graceful draining, rotating workload-identity files, confined mounted-vault resolution, a redacted activation preflight and live rotation drill, a non-root container, and a hardened two-replica Kubernetes template. The preflight checks exact decoded issuer/audience/subject and bounded lifetime but explicitly does not claim signature verification; Convex remains the verifier. The repository does not claim that a trusted issuer/audience, service membership, secret-store CSI provider, digest-pinned image, independent failure-domain replicas, or alert destination is currently live. Production posture therefore remains `credential activation required`; see `docs/SOURCE_WORKER_SERVICE.md`.
+
+## Execution safety
+
+`execution.enqueue` evaluates all required source groups before admission counters, credit reservation, lease creation, or job persistence. A blocked group returns:
+
+```text
+E_AUTHORITATIVE_SOURCES_NOT_READY:<group>:<exact-reason>
+```
+
+Agents without configured required groups preserve existing behavior. This supports staged adoption while regulated templates can require the control explicitly.
+
+## Production activation checklist
+
+- Deploy at least two independently failing worker paths for critical groups.
+- Resolve endpoint and licence references only inside the worker's secret boundary.
+- Schedule checks faster than each source freshness SLO.
+- Send alerts before maximum age, not after it.
+- Use circuit breakers, bounded retry with jitter, rate-limit awareness, and cached metadata only within licence terms.
+- Record content digests and publisher timestamps where permitted.
+- Exercise primary outage, fallback outage, credential expiry, rate limit, and stale-cache drills.
+- Monitor the source-control gate itself from another failure domain.
+
+Until those external controls are activated and measured, the UI correctly labels the feature `supervised source assurance`.