factoryline-code-factory 0.46.2__tar.gz → 0.46.3__tar.gz

{factoryline_code_factory-0.46.2 → factoryline_code_factory-0.46.3}/.zenodo.json

@@ -1,8 +1,8 @@
 {
   "title": "Code Factory: Proof-by-Sabotage Software Factory",
-  "description": "Your AI can say the test passed. Code Factory asks whether the test could ever have failed. Solo developers start with one local proof; teams bind the real diff, sealed intent, independent checks, and receipts instead of trusting an agent's narrative. Core version 0.46.0 adds a read-only Agent Proof Bridge for Eve, Junie, Grok Build, and generic clients; FactoryLine IDE adapters are version 0.9.0. The bridge verifies a typed acyclic workflow DAG, scoped source preconditions, real before/after artifact hashes, provider-declared checkpoint continuity, and the current Oracle Contract without contacting or operating an external agent. It also produces local, review-required Proof Worklog drafts from sealed evidence only; it never posts to a ticketing, chat, or source-control service. The deterministic AppForge App Review evidence gate remains visible in FactoryLine: 30 policy and release-risk checks bind the exact app build to the required local evidence and preserve named human control. Inspect a hash-verified iOS review story, user design input, Graph Ops mission-control storyboard, quality evidence, and submission dossier before entering the queue. The workflow is designed to reduce avoidable App Review rework and waiting time; it does not guarantee approval or claim a measured rejection-rate reduction.\n\nSupplied local observations are not provider certification, payment settlement, production proof, security or compliance certification, or release authority.\n\nDual licensed under MIT or Apache-2.0.",
-  "version": "0.46.2",
-  "publication_date": "2026-09-02",
+  "description": "Your AI can say the test passed. Code Factory asks whether the test could ever have failed. Solo developers start with one local proof; teams bind the real diff, sealed intent, independent checks, and receipts instead of trusting an agent's narrative. Core version 0.46.3 includes a read-only Agent Proof Bridge for Eve, Junie, Grok Build, and generic clients; FactoryLine IDE adapters are version 0.9.4 for VS Code and 0.9.2 for JetBrains. The bridge verifies a typed acyclic workflow DAG, scoped source preconditions, real before/after artifact hashes, provider-declared checkpoint continuity, and the current Oracle Contract without contacting or operating an external agent. It also produces local, review-required Proof Worklog drafts from sealed evidence only; it never posts to a ticketing, chat, or source-control service. The deterministic AppForge App Review evidence gate remains visible in FactoryLine: 30 policy and release-risk checks bind the exact app build to the required local evidence and preserve named human control. Inspect a hash-verified iOS review story, user design input, Graph Ops mission-control storyboard, quality evidence, and submission dossier before entering the queue. The workflow is designed to reduce avoidable App Review rework and waiting time; it does not guarantee approval or claim a measured rejection-rate reduction.\n\nSupplied local observations are not provider certification, payment settlement, production proof, security or compliance certification, or release authority.\n\nDual licensed under MIT or Apache-2.0.",
+  "version": "0.46.3",
+  "publication_date": "2026-09-05",
   "creators": [
     {
       "name": "Katz, Richard"

{factoryline_code_factory-0.46.2 → factoryline_code_factory-0.46.3}/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.46.2
-date-released: 2026-09-02
+version: 0.46.3
+date-released: 2026-09-05

{factoryline_code_factory-0.46.2 → factoryline_code_factory-0.46.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: factoryline-code-factory
-Version: 0.46.2
+Version: 0.46.3
 Summary: Catch hollow AI tests and App Store evidence gaps before review.
 Author: Richard Katz
 Author-email: rkatz22@gmail.com
@@ -60,22 +60,111 @@ Dynamic: license-file
 
 <!-- mcp-name: io.github.zrk222/code-factory -->
 
-> **Catch AI-generated tests that could never fail — before review.**
+> **6 mandatory audit lanes. 136 coded rejection conditions. One human-owned release decision.**
 
-> **One command answers one question: can this test actually fail?** Code Factory
-> runs a safe negative control, records what happened, and gives you a local
-> result you can review. It challenges whether a test can actually reject the
-> failure it claims to cover. It does not upload your code or call a green test
-> proof when that test could never catch the failure.
+## Your code passed. But did it pass the right tests?
+
+An AI agent—or a human developer—can write the code, write the tests, and set
+the rules used to approve its own work. Everything can turn green while the
+result still misses the request, leaks another tenant's data, breaks during a
+retry, damages a migration, or slows down in production.
+
+**Code Factory is an engineering audit and orchestration system: the independent
+review layer between “the build passed” and “a person should approve this.”**
+
+It seals the original intent before work begins, observes what changed,
+challenges the implementation and its tests, and connects every decision to
+inspectable evidence. If evidence is missing, contradictory, stale, or based on
+a weakened rule, the result does not quietly become a pass.
+
+### One review path, six questions
+
+| Audit lane | The practical question it answers |
+| --- | --- |
+| Stateful workflows | Do business rules still hold after real sequences such as create, cancel, retry, and refund? |
+| Authorization and tenant isolation | Can one customer, session, export, cache, or background job reach another customer's data? |
+| Failure and recovery | What happens during duplicate requests, timeouts, partial writes, worker crashes, and retries? |
+| API and consumer compatibility | Will this change silently break an older app, SDK, integration, or service? |
+| Migration and data integrity | Can the system upgrade without losing, corrupting, or stranding data? |
+| Performance and resources | Did latency, queries, memory, connections, or other resources regress against an approved baseline? |
+
+Those lanes contain **81 lane-specific and 55 cross-cutting coded rejection
+conditions**. The [source-bound inventory](docs/AUDIT_CONDITION_INVENTORY.md)
+recomputes the total from the implementation; it is not a claim that every
+project executes 136 tests.
+
+### Built for the way you work
+
+- **Solo developers and vibe coders:** get a second opinion before a plausible
+  AI-generated change becomes your problem in production.
+- **Engineering teams:** compare the request, code delta, independent checks,
+  repair evidence, and remaining unknowns in one reviewable handoff.
+- **Enterprise teams:** keep policy provenance, exceptions, approvals, tenant
+  boundaries, and evidence traceable without giving the coding agent authority
+  to redefine success.
+- **Connected agents:** use the CLI, FactoryLine IDE surfaces, MCP, WebMCP, or
+  A2A handoffs to follow the same bounded process and report the next action to
+  a human.
+
+Specialist modules join the same review when needed: Deep Defect Mesh consumes
+analyzer evidence, SaaS checks examine customer journeys, and AppForge organizes
+mobile build, design, privacy, signing, and store-submission evidence. AppForge
+does not replace the other audit lanes or promise store approval.
+
+### Choose your review path
 
 ```powershell
 pip install factoryline-code-factory
-factory first-proof --root .
+factory guide
 ```
 
-That one local command creates a disposable demonstration sandbox, proves the
-healthy check can pass, then proves the hollow check is rejected. It writes a
-receipt and a privacy-safe Proof Card; it does not assess or change your project.
+`factory guide` is a read-only orientation: it shows the smallest suitable path
+without running tests or agents. When you are ready to produce evidence, follow
+the [engineering review workflow](docs/PROOF_REVIEW_WORKFLOW.md). Its result
+shows **what was checked, what failed, why it matters, what evidence supports
+the finding, and what must happen next.** Code Factory does not promise perfect
+software. It makes the basis for approval visible and keeps the final decision
+human-owned.
+
+<details>
+<summary>For developers: how the review connects across modules</summary>
+
+## From a plausible change to an inspectable engineering decision
+
+- **Build what was actually requested.** SpecLine clarifies requirements;
+  sealed intent and Oracle Firewall checks flag scope drift and weakened gates.
+- **Review behavior beyond a green unit test.** Six audit lanes coordinate
+  stateful invariants, authorization and tenant isolation, failure/concurrency
+  recovery, API compatibility, database migration, and performance/resource
+  regressions. Each lane needs the appropriate runner and real evidence.
+- **Turn findings into repair work.** Deep Defect Mesh checks supplied analyzer
+  evidence; linked traces and repair comparisons keep consequences, stale
+  results, and the next validation visible.
+- **Keep the handoff coherent.** ForgeLine orchestration and FactoryLine
+  receipts connect work across modules. Mission Control and Graph Ops show
+  humans and connected agents the same scope, blockers, evidence, and next step.
+- **Activate specialist checks when needed.** SaaS journey checks and AppForge
+  mobile-release evidence fit into the same review path. AppForge is an
+  optional module, not the whole product.
+
+**The payoff:** a reviewer can see what was audited, what passed, what remains
+unknown, and what must happen next. A receipt supports that decision; it is not
+a guarantee of defect-free code, enterprise certification, or store approval.
+People retain authority over policy, exceptions, and release.
+
+</details>
+
+Install the CLI, then follow the
+[engineering review workflow](docs/PROOF_REVIEW_WORKFLOW.md) for a full review:
+
+```powershell
+pip install factoryline-code-factory
+```
+
+Want a small demonstration first? `factory first-proof --root .` challenges
+whether a test can actually reject its declared failure in a disposable sandbox.
+It writes a receipt and a privacy-safe Proof Card; it does not assess or change
+your project. First Proof is one entry point—not the scope of the full audit.
 
 **LLM-friendly product context:** [Canonical Product Card](docs/LLM_PRODUCT_CARD.md)
 states the supported capabilities, boundaries, audiences, integration terms,
@@ -90,11 +179,13 @@ signed analyzer-report contracts, flags missing negative controls, traces findin
 into Graph Ops, and compares repair outcomes. It coordinates supplied evidence;
 it does not execute the analyzers or guarantee that a clean report means safe code.
 
-Run `factory guide` to see the same three choices in any terminal:
+Choose your review path below. The current `factory guide` command still lists
+the existing onboarding paths, including the solo First Proof demo; it is not
+the full engineering-review workflow linked above.
 
-- **Individual developer:** *Can this test actually fail?* Start with `factory
-  first-proof --root .`. You get one local result and a receipt without changing
-  your project.
+- **Individual developer or vibe coder:** *What did my change miss?* Use the
+  engineering review workflow to inspect intent, behavior, and evidence. Try
+  `factory first-proof --root .` for a contained demonstration first.
 - **Engineering team:** *Did the agent build what we asked for?* Start with
   `factory oracle status --root .`. Bind the original intent, observe the exact
   file delta, challenge the tests independently, and keep approval human-owned.
@@ -103,7 +194,7 @@ Run `factory guide` to see the same three choices in any terminal:
   source-to-decision chain, blockers, unknowns, and authority boundaries in a
   controlled pilot.
 
-That is the whole front door. Specialized SaaS, mobile, multi-repository, and
+Choose the relevant audit scope. Specialized SaaS, mobile, multi-repository, and
 enterprise controls remain available in the [advanced workflow guide](docs/OVERVIEW.md)
 only when their trigger applies. AppForge is an optional mobile-delivery
 capability; it surfaces avoidable gaps but cannot guarantee store approval.
@@ -115,6 +206,27 @@ checks under one signed plan. Every failed lane returns the consequence,
 evidence digest, exact replay, and next repair. A six-lane pass means ready for
 human review—not approved for release.
 
+### Senior engineering controls in 0.46.3
+
+When a team needs stronger evidence than a self-reported green build, use the
+[senior-engineering integration](docs/SENIOR_ENGINEERING_INTEGRATION.md):
+
+- verify an independently collected, candidate-bound execution attestation;
+- measure a reviewed buggy/fixed defect corpus with case-level recall and
+  precision; and
+- route a dependency DAG through `RUN`, `REUSE`, `SKIP`, or `BLOCK`, then compare
+  the incremental plan with a full baseline;
+- reproduce a failure in a fresh, contract-bound process workspace, compare the
+  original failure with a repair and negative controls, explain every reuse
+  decision across policy/dependency/toolchain/environment fingerprints, and
+  hand a reviewer a runnable, evidence-linked failure briefing.
+
+These adapters are provider-neutral and review-only. Replay and repair execute
+only when the operator supplies `--execute`; they use a fresh temporary process
+workspace with a secret-free environment, not a kernel/container sandbox. They
+never publish a package or approve a release. Missing independent evidence
+remains an evidence gap.
+
 Do not take the word *verified* on faith. The [Capability Evidence Map](docs/CAPABILITY_EVIDENCE.md)
 separates the locally verified core, controlled-pilot workflows, reference
 enterprise controls, and candidate-bound mobile preflight—and links each claim
@@ -253,7 +365,7 @@ security, productivity, production readiness, or an automatic repair service.
 | --- | --- | --- | --- |
 | **Individual developer / vibe coder** | `factory first-proof` | See whether a passing test can actually reject a known failure before trusting it | A local receipt and privacy-safe Proof Card from a disposable demonstration; your project remains unchanged |
 | **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 |
+| **Senior / staff engineer** | `factory senior replay|repair|reuse|brief`, then `factory judgment` and `factory graph forensics` | Reproduce the exact failure, prove a repair without weakening negative controls, refuse unsafe proof reuse, and brief the team in one evidence-linked handoff | Source/dependency/policy-bound replays, original-vs-fix comparisons, explicit reuse explanations, runnable reproducers, uncertainty, and next action |
 | **Engineering team** | `factory wrap`, then GitHub Proof Review | Record the exact agent-created file delta, run declared independent validators, and hand reviewers a commit-bound evidence packet without retaining prompts | Local receipts, exact changed paths, explicit blockers, and a neutral PR Check beside AI review |
 | **Platform / assurance pilot** | Policy gates and evidence packets | Evaluate named approval boundaries, expiring exceptions, tenant isolation, budgets, and release evidence inside existing SDLC controls | Independently verifiable packets and read-only views; identity, credentials, merge, release, and deployment remain enterprise-owned. No SLA, certification, references, or procurement-readiness claim |
 | **Enterprise support evaluator** | Support and operating requirements | Review the proposed response, availability, recovery, exclusions, and activation evidence before procurement | [Support SLA policy](docs/SUPPORT_SLA.md); terms remain proposed until a signed order and all activation gates are evidenced |
@@ -459,6 +571,12 @@ AppForge Builder at **$24/month or $240/year**, and Team Assurance at **$20 per
 active contributor/month annually or $24 monthly**, subject to explicit activation gates. See the
 [Open VSX service plan](docs/OPEN_VSX_MONETIZATION_2026.md).
 
+Release owners can use the read-only [release candidate preflight](docs/RELEASE_CANDIDATE_PREFLIGHT.md)
+to bind source, commit, platform artifacts, and active metadata before any
+upload. The [Codex metadata integrity](docs/CODEX_METADATA_INTEGRITY.md) audit
+keeps archival claims out of active proof, and [Windows process binding](docs/WINDOWS_PROCESS_BINDING.md)
+closes the bind-before-run process-tree race.
+
 ## The proof boundary
 
 Code Factory creates and inspects local artifacts. It does **not** silently call a
@@ -500,7 +618,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 [0.46.2 core release notes](docs/RELEASE_NOTES_0.46.2.md), the
+- See the [0.46.3 core release notes](docs/RELEASE_NOTES_0.46.3.md), the
   [grilling ladder](docs/GRILLING_LADDER.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.46.2 → factoryline_code_factory-0.46.3}/README.md

@@ -9,22 +9,111 @@
 
 <!-- mcp-name: io.github.zrk222/code-factory -->
 
-> **Catch AI-generated tests that could never fail — before review.**
+> **6 mandatory audit lanes. 136 coded rejection conditions. One human-owned release decision.**
+
+## Your code passed. But did it pass the right tests?
+
+An AI agent—or a human developer—can write the code, write the tests, and set
+the rules used to approve its own work. Everything can turn green while the
+result still misses the request, leaks another tenant's data, breaks during a
+retry, damages a migration, or slows down in production.
+
+**Code Factory is an engineering audit and orchestration system: the independent
+review layer between “the build passed” and “a person should approve this.”**
+
+It seals the original intent before work begins, observes what changed,
+challenges the implementation and its tests, and connects every decision to
+inspectable evidence. If evidence is missing, contradictory, stale, or based on
+a weakened rule, the result does not quietly become a pass.
+
+### One review path, six questions
+
+| Audit lane | The practical question it answers |
+| --- | --- |
+| Stateful workflows | Do business rules still hold after real sequences such as create, cancel, retry, and refund? |
+| Authorization and tenant isolation | Can one customer, session, export, cache, or background job reach another customer's data? |
+| Failure and recovery | What happens during duplicate requests, timeouts, partial writes, worker crashes, and retries? |
+| API and consumer compatibility | Will this change silently break an older app, SDK, integration, or service? |
+| Migration and data integrity | Can the system upgrade without losing, corrupting, or stranding data? |
+| Performance and resources | Did latency, queries, memory, connections, or other resources regress against an approved baseline? |
+
+Those lanes contain **81 lane-specific and 55 cross-cutting coded rejection
+conditions**. The [source-bound inventory](docs/AUDIT_CONDITION_INVENTORY.md)
+recomputes the total from the implementation; it is not a claim that every
+project executes 136 tests.
+
+### Built for the way you work
+
+- **Solo developers and vibe coders:** get a second opinion before a plausible
+  AI-generated change becomes your problem in production.
+- **Engineering teams:** compare the request, code delta, independent checks,
+  repair evidence, and remaining unknowns in one reviewable handoff.
+- **Enterprise teams:** keep policy provenance, exceptions, approvals, tenant
+  boundaries, and evidence traceable without giving the coding agent authority
+  to redefine success.
+- **Connected agents:** use the CLI, FactoryLine IDE surfaces, MCP, WebMCP, or
+  A2A handoffs to follow the same bounded process and report the next action to
+  a human.
+
+Specialist modules join the same review when needed: Deep Defect Mesh consumes
+analyzer evidence, SaaS checks examine customer journeys, and AppForge organizes
+mobile build, design, privacy, signing, and store-submission evidence. AppForge
+does not replace the other audit lanes or promise store approval.
+
+### Choose your review path
 
-> **One command answers one question: can this test actually fail?** Code Factory
-> runs a safe negative control, records what happened, and gives you a local
-> result you can review. It challenges whether a test can actually reject the
-> failure it claims to cover. It does not upload your code or call a green test
-> proof when that test could never catch the failure.
+```powershell
+pip install factoryline-code-factory
+factory guide
+```
+
+`factory guide` is a read-only orientation: it shows the smallest suitable path
+without running tests or agents. When you are ready to produce evidence, follow
+the [engineering review workflow](docs/PROOF_REVIEW_WORKFLOW.md). Its result
+shows **what was checked, what failed, why it matters, what evidence supports
+the finding, and what must happen next.** Code Factory does not promise perfect
+software. It makes the basis for approval visible and keeps the final decision
+human-owned.
+
+<details>
+<summary>For developers: how the review connects across modules</summary>
+
+## From a plausible change to an inspectable engineering decision
+
+- **Build what was actually requested.** SpecLine clarifies requirements;
+  sealed intent and Oracle Firewall checks flag scope drift and weakened gates.
+- **Review behavior beyond a green unit test.** Six audit lanes coordinate
+  stateful invariants, authorization and tenant isolation, failure/concurrency
+  recovery, API compatibility, database migration, and performance/resource
+  regressions. Each lane needs the appropriate runner and real evidence.
+- **Turn findings into repair work.** Deep Defect Mesh checks supplied analyzer
+  evidence; linked traces and repair comparisons keep consequences, stale
+  results, and the next validation visible.
+- **Keep the handoff coherent.** ForgeLine orchestration and FactoryLine
+  receipts connect work across modules. Mission Control and Graph Ops show
+  humans and connected agents the same scope, blockers, evidence, and next step.
+- **Activate specialist checks when needed.** SaaS journey checks and AppForge
+  mobile-release evidence fit into the same review path. AppForge is an
+  optional module, not the whole product.
+
+**The payoff:** a reviewer can see what was audited, what passed, what remains
+unknown, and what must happen next. A receipt supports that decision; it is not
+a guarantee of defect-free code, enterprise certification, or store approval.
+People retain authority over policy, exceptions, and release.
+
+</details>
+
+Install the CLI, then follow the
+[engineering review workflow](docs/PROOF_REVIEW_WORKFLOW.md) for a full review:
 
 ```powershell
 pip install factoryline-code-factory
-factory first-proof --root .
 ```
 
-That one local command creates a disposable demonstration sandbox, proves the
-healthy check can pass, then proves the hollow check is rejected. It writes a
-receipt and a privacy-safe Proof Card; it does not assess or change your project.
+Want a small demonstration first? `factory first-proof --root .` challenges
+whether a test can actually reject its declared failure in a disposable sandbox.
+It writes a receipt and a privacy-safe Proof Card; it does not assess or change
+your project. First Proof is one entry point—not the scope of the full audit.
 
 **LLM-friendly product context:** [Canonical Product Card](docs/LLM_PRODUCT_CARD.md)
 states the supported capabilities, boundaries, audiences, integration terms,
@@ -39,11 +128,13 @@ signed analyzer-report contracts, flags missing negative controls, traces findin
 into Graph Ops, and compares repair outcomes. It coordinates supplied evidence;
 it does not execute the analyzers or guarantee that a clean report means safe code.
 
-Run `factory guide` to see the same three choices in any terminal:
+Choose your review path below. The current `factory guide` command still lists
+the existing onboarding paths, including the solo First Proof demo; it is not
+the full engineering-review workflow linked above.
 
-- **Individual developer:** *Can this test actually fail?* Start with `factory
-  first-proof --root .`. You get one local result and a receipt without changing
-  your project.
+- **Individual developer or vibe coder:** *What did my change miss?* Use the
+  engineering review workflow to inspect intent, behavior, and evidence. Try
+  `factory first-proof --root .` for a contained demonstration first.
 - **Engineering team:** *Did the agent build what we asked for?* Start with
   `factory oracle status --root .`. Bind the original intent, observe the exact
   file delta, challenge the tests independently, and keep approval human-owned.
@@ -52,7 +143,7 @@ Run `factory guide` to see the same three choices in any terminal:
   source-to-decision chain, blockers, unknowns, and authority boundaries in a
   controlled pilot.
 
-That is the whole front door. Specialized SaaS, mobile, multi-repository, and
+Choose the relevant audit scope. Specialized SaaS, mobile, multi-repository, and
 enterprise controls remain available in the [advanced workflow guide](docs/OVERVIEW.md)
 only when their trigger applies. AppForge is an optional mobile-delivery
 capability; it surfaces avoidable gaps but cannot guarantee store approval.
@@ -64,6 +155,27 @@ checks under one signed plan. Every failed lane returns the consequence,
 evidence digest, exact replay, and next repair. A six-lane pass means ready for
 human review—not approved for release.
 
+### Senior engineering controls in 0.46.3
+
+When a team needs stronger evidence than a self-reported green build, use the
+[senior-engineering integration](docs/SENIOR_ENGINEERING_INTEGRATION.md):
+
+- verify an independently collected, candidate-bound execution attestation;
+- measure a reviewed buggy/fixed defect corpus with case-level recall and
+  precision; and
+- route a dependency DAG through `RUN`, `REUSE`, `SKIP`, or `BLOCK`, then compare
+  the incremental plan with a full baseline;
+- reproduce a failure in a fresh, contract-bound process workspace, compare the
+  original failure with a repair and negative controls, explain every reuse
+  decision across policy/dependency/toolchain/environment fingerprints, and
+  hand a reviewer a runnable, evidence-linked failure briefing.
+
+These adapters are provider-neutral and review-only. Replay and repair execute
+only when the operator supplies `--execute`; they use a fresh temporary process
+workspace with a secret-free environment, not a kernel/container sandbox. They
+never publish a package or approve a release. Missing independent evidence
+remains an evidence gap.
+
 Do not take the word *verified* on faith. The [Capability Evidence Map](docs/CAPABILITY_EVIDENCE.md)
 separates the locally verified core, controlled-pilot workflows, reference
 enterprise controls, and candidate-bound mobile preflight—and links each claim
@@ -202,7 +314,7 @@ security, productivity, production readiness, or an automatic repair service.
 | --- | --- | --- | --- |
 | **Individual developer / vibe coder** | `factory first-proof` | See whether a passing test can actually reject a known failure before trusting it | A local receipt and privacy-safe Proof Card from a disposable demonstration; your project remains unchanged |
 | **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 |
+| **Senior / staff engineer** | `factory senior replay|repair|reuse|brief`, then `factory judgment` and `factory graph forensics` | Reproduce the exact failure, prove a repair without weakening negative controls, refuse unsafe proof reuse, and brief the team in one evidence-linked handoff | Source/dependency/policy-bound replays, original-vs-fix comparisons, explicit reuse explanations, runnable reproducers, uncertainty, and next action |
 | **Engineering team** | `factory wrap`, then GitHub Proof Review | Record the exact agent-created file delta, run declared independent validators, and hand reviewers a commit-bound evidence packet without retaining prompts | Local receipts, exact changed paths, explicit blockers, and a neutral PR Check beside AI review |
 | **Platform / assurance pilot** | Policy gates and evidence packets | Evaluate named approval boundaries, expiring exceptions, tenant isolation, budgets, and release evidence inside existing SDLC controls | Independently verifiable packets and read-only views; identity, credentials, merge, release, and deployment remain enterprise-owned. No SLA, certification, references, or procurement-readiness claim |
 | **Enterprise support evaluator** | Support and operating requirements | Review the proposed response, availability, recovery, exclusions, and activation evidence before procurement | [Support SLA policy](docs/SUPPORT_SLA.md); terms remain proposed until a signed order and all activation gates are evidenced |
@@ -408,6 +520,12 @@ AppForge Builder at **$24/month or $240/year**, and Team Assurance at **$20 per
 active contributor/month annually or $24 monthly**, subject to explicit activation gates. See the
 [Open VSX service plan](docs/OPEN_VSX_MONETIZATION_2026.md).
 
+Release owners can use the read-only [release candidate preflight](docs/RELEASE_CANDIDATE_PREFLIGHT.md)
+to bind source, commit, platform artifacts, and active metadata before any
+upload. The [Codex metadata integrity](docs/CODEX_METADATA_INTEGRITY.md) audit
+keeps archival claims out of active proof, and [Windows process binding](docs/WINDOWS_PROCESS_BINDING.md)
+closes the bind-before-run process-tree race.
+
 ## The proof boundary
 
 Code Factory creates and inspects local artifacts. It does **not** silently call a
@@ -449,7 +567,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 [0.46.2 core release notes](docs/RELEASE_NOTES_0.46.2.md), the
+- See the [0.46.3 core release notes](docs/RELEASE_NOTES_0.46.3.md), the
   [grilling ladder](docs/GRILLING_LADDER.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.46.2 → factoryline_code_factory-0.46.3}/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.46.2
+python -m pip install factoryline-code-factory==0.46.3
 factory mcp status --root C:\work\my-mvp --json
 factory mcp config --client generic --root C:\work\my-mvp --json
 ```

factoryline_code_factory-0.46.3/docs/AUDIT_CONDITION_INVENTORY.md

@@ -0,0 +1,30 @@
+# Runtime audit condition inventory
+
+Code Factory's senior-engineering runtime-assurance path has:
+
+**6 mandatory audit lanes. 136 coded rejection conditions. One human-owned release decision.**
+
+The source inventory comprises **81 lane-specific and 55 cross-cutting** conditions:
+
+| Audit area | Coded rejection conditions |
+| --- | ---: |
+| Stateful workflows and business invariants | 12 |
+| Authorization and tenant isolation | 11 |
+| Failure, concurrency, retries and recovery | 16 |
+| API and consumer compatibility | 10 |
+| Database migration and data integrity | 12 |
+| Performance, memory and resource regression | 20 |
+| Cross-cutting contract, policy, provenance, evidence and execution integrity | 55 |
+| **Total** | **136** |
+
+Run `python scripts/audit_condition_inventory.py` to recompute the inventory
+from the implementation. CI requires the public totals to match that output.
+
+This is a source inventory, not a claim that every project executes 136 tests.
+The six lanes are mandatory for a complete runtime-assurance decision, while
+the observations within each lane scale with the approved invariants, tenant
+surfaces, fault modes, consumers, tables, thresholds and evidence supplied for
+that project. Missing tooling or evidence remains incomplete rather than pass.
+
+Oracle Firewall, SpecLine, Deep Defect Mesh, AppForge and other conditional
+modules add checks outside this narrowly defined runtime-assurance inventory.

factoryline_code_factory-0.46.3/docs/CODEX_METADATA_INTEGRITY.md

@@ -0,0 +1,14 @@
+# Codex metadata integrity
+
+`factory ops metadata` audits local Codex/ForgeLine records without executing
+their commands. Active records are the release-safe default; `--scope archive`
+explicitly inspects historical terminal records, and `--scope all` returns
+both. Every finding carries `scope: active` or `scope: archive`.
+
+The audit rejects unbound terminal claims, self-attested gates, weak evidence,
+unclear intent, malformed input, out-of-order progress timestamps, stale
+`head=` values, and terminal `.forge` state without hash-bearing sibling
+receipt lineage. Archive history is never promoted into active release proof.
+Receipts use `factory.codex-metadata-integrity.v1` with `schema_version: 2` and
+remain authority-free; they are evidence for review, not approval or
+publication.

{factoryline_code_factory-0.46.2 → factoryline_code_factory-0.46.3}/docs/FIRST_USE.md

@@ -5,7 +5,7 @@ small feature or risky workflow, not a whole migration.
 
 ```powershell
 cd path\to\your-repository
-pip install factoryline-code-factory==0.46.2 code-factory-1-spec==0.5.4 code-factory-2-forge==0.10.7
+pip install factoryline-code-factory==0.46.3 code-factory-1-spec==0.5.4 code-factory-2-forge==0.10.7
 factory doctor --json
 factory init .
 forge adopt <feature> --root .

{factoryline_code_factory-0.46.2 → factoryline_code_factory-0.46.3}/docs/INTELLIJ.md

@@ -143,7 +143,7 @@ candidate files.
 1. Install FactoryLine:
 
    ```powershell
-   pip install factoryline-code-factory==0.46.2
+   pip install factoryline-code-factory==0.46.3
    ```
 
 2. In your JetBrains IDE, open **Settings > Plugins > Marketplace**, search for

{factoryline_code_factory-0.46.2 → factoryline_code_factory-0.46.3}/docs/JETBRAINS_MARKETPLACE.md

@@ -71,12 +71,12 @@ generated ZIP, including Marketplace metadata, icons, and change notes. Compatib
 WebStorm, Rider, CLion, GoLand, RustRover, and DataGrip from the 2025.2 platform
 baseline forward.
 
-The release candidate also carries a concise [JetBrains reviewer summary](JETBRAINS_REVIEWER_SUMMARY_0_9_0.md)
+The release candidate also carries a concise [JetBrains reviewer summary](JETBRAINS_REVIEWER_SUMMARY_0_9_3.md)
 that maps each local claim to its guardrail and source-level or package-level
 evidence. Marketplace account-side requirements and manual moderation remain
 external gates, never local claims.
 
-Use the strict [0.9.0 compliance checklist](JETBRAINS_MARKETPLACE_COMPLIANCE_0_9_0.md)
+Use the strict [0.9.3 compliance checklist](JETBRAINS_MARKETPLACE_COMPLIANCE_0_9_3.md)
 before a dispatch, and keep post-approval discovery/review work inside the
 prepared, policy-compliant [growth plan](JETBRAINS_POST_RELEASE_GROWTH.md).
 
@@ -88,7 +88,7 @@ prepared, policy-compliant [growth plan](JETBRAINS_POST_RELEASE_GROWTH.md).
    must return `MARKETPLACE_UPDATE_CLEAR`.
 2. Merge the tested release commit to `main`.
 3. Create the immutable tag matching the plugin version, currently
-   `jetbrains-v0.9.0` after the remaining Marketplace metadata review is clear.
+   `jetbrains-v0.9.3` after the remaining Marketplace metadata review is clear.
 4. Run **Publish JetBrains Marketplace plugin** with that tag and the intended
    channel. The `JETBRAINS_MARKETPLACE_TOKEN` remains scoped to the protected
    `jetbrains-marketplace` environment.

factoryline_code_factory-0.46.3/docs/JETBRAINS_MARKETPLACE_COMPLIANCE_0_9_3.md

@@ -0,0 +1,14 @@
+# FactoryLine 0.9.3 — Marketplace compliance evidence map
+
+| Requirement or review risk | 0.9.3 evidence | Status and boundary |
+| --- | --- | --- |
+| Identity and version | `editors/intellij/build.gradle.kts` declares `0.9.3`; `plugin.xml` keeps id `app.factoryline`; `editors/intellij/CHANGELOG.md` leads with `0.9.3`. | Local metadata is aligned; a Marketplace listing read-back is still required. |
+| User-facing value | `plugin.xml` and the IntelliJ README lead with First Proof, six audit lanes, and the senior evidence controls. | Copy is source-reviewable; moderation and listing presentation remain external. |
+| Independent evidence boundary | `factoryline.independent_execution` verifies signed candidate/plan/runner bindings, freshness, cleanup, and resource observations while rejecting supervised-only assurance. | The package verifies supplied attestations; it does not host or prove the runner. |
+| Defect quality | `factoryline.benchmark_lab` requires immutable source/bug/fix digests and emits case-level precision/recall; missed known defects block the receipt. | The corpus and replay execution are supplied by the reviewer. |
+| Safe incremental review | `factoryline.incremental_scheduler` validates DAGs, dependency closure, side effects, assurance drift, and incremental/full shadow equivalence. | Planning is review-only; no gate or provider action runs. |
+| Reproducible remediation | `factoryline.senior_assurance` replays the exact source/dependency/policy/input contract, compares original/fix/negative controls, explains safe reuse, and emits an evidence-linked failure briefing. | Replay is bounded process/workspace isolation; it is not a kernel/container sandbox and cannot approve a Marketplace submission. |
+| Release controls | `guardianReleaseGate`, Plugin Verifier, signing, and protected Marketplace workflow remain required. | Upload, processing, manual moderation, and approval are JetBrains-only external states. |
+
+This checklist records local evidence and boundaries. It does not promise
+Marketplace acceptance or approval.

factoryline_code_factory-0.46.3/docs/JETBRAINS_REVIEWER_SUMMARY_0_9_3.md

@@ -0,0 +1,37 @@
+# FactoryLine 0.9.3 — reviewer summary
+
+FactoryLine is a local, review-only proof layer for AI-assisted development.
+The 0.9.3 adapter adds seven concrete senior-engineering controls without
+granting the IDE, agent, or plugin release authority:
+
+- **Independent execution:** a DSSE-signed observation binds the candidate and
+  plan to a runner identity/executable, nonce, cleanup, memory/latency, and
+  target/known-bad artifacts. A supervised local observation cannot be labeled
+  independent.
+- **Real-defect benchmark:** reviewers can supply a bounded buggy/fixed corpus
+  and see case-level findings plus per-category precision and recall. A missed
+  known defect or failed fix is `BLOCKED`.
+- **Dependency-aware proof routing:** a declared DAG produces exact `RUN`,
+  `REUSE`, `SKIP`, or `BLOCK` dispositions. Unknown dependency closure,
+  side-effecting work, assurance drift, and blocked prerequisites fail closed.
+  A shadow command compares incremental and full obligations/findings before a
+  skip is reviewed.
+- **Independent replay:** `factory senior replay --execute` binds exact source,
+  dependency, policy, input, argv, and contract digests to a fresh temporary
+  workspace and child invocation with a secret-free environment. The receipt
+  explicitly does not claim kernel/container isolation.
+- **Executable repair comparison:** `factory senior repair --execute` keeps the
+  original failing leg, repaired leg, and negative controls together. A repair
+  is not a pass if the original did not fail or a negative control was weakened;
+  changed expectations require a named reviewer and reason.
+- **Evidence reuse explanation:** `factory senior reuse` compares policy,
+  dependencies, toolchain, environment, receipt, and changed-input fingerprints.
+  Unknown facts route to `RUN`; side effects route to `BLOCK`.
+- **Failure briefing:** `factory senior brief` turns a failed receipt into
+  `what broke`, affected scope, reproduction, next fix, uncertainty, and linked
+  evidence so a reviewer can act without reconstructing the run from chat.
+
+Every result is bounded JSON with a digest and `authority: none`; all adapters
+remain review-only. Replay and repair execute only after explicit `--execute`
+and do not access credentials, upload source, publish, deploy, or approve
+releases. The human reviewer retains the final decision.