tradingcodex 0.2.5__tar.gz → 0.2.7__tar.gz

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: tradingcodex
-Version: 0.2.5
+Version: 0.2.7
 Summary: Codex-native trading harness with a Django service plane and approved action boundary.
 Author: TradingCodex Authors
 License-Expression: Apache-2.0
@@ -59,8 +59,8 @@ Dynamic: license-file
 
 TradingCodex is a local-first Python/Django trading harness for rigorous
 Codex-assisted research, portfolio review, order-ticket checks, approvals, and
-experimental non-live submission checks. Codex coordinates the work, Django
-owns the durable service plane, and TradingCodex owns the executable boundary.
+service-gated execution checks. Codex coordinates the work, Django owns the
+durable service plane, and TradingCodex owns the executable boundary.
 
 [Quick Start](#installation) | [Docs](docs/README.md) | [Safety](docs/safety-policy-and-execution.md) | [Architecture](docs/system-architecture.md) | [Contributing](CONTRIBUTING.md) | [License](LICENSE)
 
@@ -78,7 +78,8 @@ policy and approval services, a central local ledger, and a local web dashboard
 for review.
 
 It is not an autonomous trading bot. Natural-language answers do not become
-broker actions. Live broker adapters are not shipped in the initial core.
+broker actions. The core ships paper execution by default; live broker support
+comes only from installed, reviewed providers and explicit live gates.
 
 ---
 
@@ -89,10 +90,11 @@ broker actions. Live broker adapters are not shipped in the initial core.
 | Codex-native harness | Generates a Codex workspace with `head-manager`, nine fixed subagents, role prompts, skills, hooks, project MCP config, and a local `./tcx` wrapper. |
 | Django service plane | Web, Admin, API, CLI, MCP, and generated hooks call shared application services for policy, orders, approvals, portfolio, audit, integrations, and research indexing. |
 | File-native research memory | Research markdown, role reports, source snapshots, versions, readiness labels, and handoff metadata stay readable in workspace files. |
+| Decision Workflow Alpha | Turn a natural-language investment idea into a Codex-native workflow plan and Decision Package under `trading/decisions/`. |
 | Fixed-role workflows | Specialist agents own bounded questions across fundamentals, technicals, news, macro, instruments, valuation, portfolio, risk, and execution. |
 | Approved action boundary | Actions are typed, role-scoped, policy-checked, approval-aware, duplicate-request checked, connection-gated, and audited. |
 | Local web dashboard | Review agents, skills, strategy skills, research markdown, Broker Center, Data Sources, order tickets, portfolio state, and activity at `127.0.0.1:48267`. |
-| Broker Center foundations | Register connector profiles, inspect capability profiles, run read-only paper sync, review instrument constraints, and reconcile portfolio state. |
+| Broker Center foundations | Connect provider-driven broker profiles, list installed providers, scaffold/register advanced connectors, inspect capability profiles, run account sync, review instrument constraints, and reconcile portfolio state. |
 | OrderTicket lifecycle | Draft, check, approve, submit, cancel, refresh, and inspect order tickets through central DB records and service-layer state transitions. |
 | Data Sources gate | Import external source discovery metadata, review available actions, scope role access, and block unsafe raw execution or secret paths by default. |
 | Improvement loop | Quality gates, postmortems, optional skills, strategy skills, strict artifact checks, and generated workspace smoke tests turn process gaps into durable improvements. |
@@ -169,8 +171,13 @@ boundaries rather than on black-box automation.
 - Deterministic executable boundary: every executable path follows
   a fixed requester, permission, policy, payload, approval, duplicate-request,
   connection, and audit sequence.
-- Safety-first broker posture: live broker execution is excluded; paper and
-  reviewed test/sandbox validation remain experimental local harness flows.
+- Safety-first broker posture: paper is built in; live broker execution requires
+  an installed provider plus workspace config, policy, environment opt-in,
+  approval, confirmation, idempotency, sync, and audit gates.
+- Broker control plane: TradingCodex stores connector state, capability
+  profiles, mapping review, approval, execution, reconciliation, and audit;
+  provider adapters absorb broker-specific REST, SDK, MCP, or manual interface
+  differences behind canonical service/MCP tools.
 
 ---
 
@@ -180,7 +187,7 @@ TradingCodex is designed around handoffs:
 
 ```text
 evidence -> analysis -> valuation -> portfolio fit -> risk review
-  -> draft order -> approval receipt -> approved non-live submission
+  -> draft order -> approval receipt -> approved service-gated submission
   -> connection result -> audit/postmortem
 ```
 
@@ -204,7 +211,7 @@ workflow has earned. Weak, stale, missing, or out-of-scope upstream work returns
 | Decision review | `valuation-analyst` | Valuation ranges, scenario assumptions, multiples, sensitivity, and decision-quality gaps. |
 | Portfolio | `portfolio-manager` | Portfolio fit, sizing, concentration, liquidity, opportunity cost, and draft order-ticket readiness. |
 | Risk | `risk-manager` | Downside, restricted-list checks, policy readiness, approval readiness, and approval receipts. |
-| Execution | `execution-operator` | Approved non-live submission through the TradingCodex service boundary only. |
+| Execution | `execution-operator` | Approved submission/cancel/status through the TradingCodex service boundary only; live requires all gates. |
 
 ---
 
@@ -218,9 +225,9 @@ workflow has earned. Weak, stale, missing, or out-of-scope upstream work returns
 | MCP | Agent/tool boundary with typed tools, role scopes, policy checks, approval checks, and audit. |
 | CLI | Local operator commands plus generated workspace `./tcx` wrapper behavior. |
 
-The baseline frontend uses Django templates, local static HTMX, and local
-static Alpine. There is no Node, bundler, React, or frontend build step in the
-core package.
+The baseline frontend uses Django templates, local static HTMX, and small plain
+JavaScript. There is no Node, bundler, React, or frontend build step in the core
+package.
 
 ---
 
@@ -236,8 +243,8 @@ TradingCodex blocks or constrains:
 - duplicate approved-order submissions
 - raw secrets in workspace files, prompts, API responses, MCP responses, audit
   payloads, generated docs, or shell output
-- unsupported live execution for crypto, macro, options, credit, FX, rates,
-  commodities, or other instruments
+- unsupported live execution through any provider, instrument, account, or
+  policy posture that has not passed the explicit live gate
 
 TradingCodex is research, workflow, and execution-guardrail tooling. It is not
 financial, investment, legal, tax, or regulatory advice, and it does not
@@ -250,9 +257,9 @@ provide investment recommendations or guarantee returns.
 | Status | Milestone |
 | --- | --- |
 | Shipped | Generated Codex workspace, fixed role roster, project MCP config, Django service plane, local web dashboard, Admin, Ninja API, file-native research memory, component registry, policy/audit primitives. |
-| Current `0.2.x` | Central-DB `OrderTicket` rewrite, Broker Center foundations, Data Sources gate, role-scoped actions, non-live execution lifecycle, and Python `>=3.11,<3.15` support. |
-| Next | Deeper validation scenarios, richer connector capability profiles, stronger generated-workspace smoke coverage, and improved artifact quality tooling. |
-| Future | Separately governed verified adapters, hosted/managed services, enterprise policy/compliance packs, and live broker support only after explicit product, policy, adapter, and validation work. |
+| Current `0.2.x` | Central-DB `OrderTicket` rewrite, provider-driven Broker Center foundations, Data Sources gate, role-scoped actions, live-gated execution lifecycle, and Python `>=3.11,<3.15` support. |
+| Next | Codex-native Decision Packages, deeper validation scenarios, richer provider capability profiles, stronger generated-workspace smoke coverage, and improved artifact quality tooling. |
+| Future | Separately governed verified adapters, hosted/managed services, enterprise policy/compliance packs, and broker-specific live providers only after explicit product, policy, adapter, and validation work. |
 
 ---
 

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/README.md

@@ -28,8 +28,8 @@
 
 TradingCodex is a local-first Python/Django trading harness for rigorous
 Codex-assisted research, portfolio review, order-ticket checks, approvals, and
-experimental non-live submission checks. Codex coordinates the work, Django
-owns the durable service plane, and TradingCodex owns the executable boundary.
+service-gated execution checks. Codex coordinates the work, Django owns the
+durable service plane, and TradingCodex owns the executable boundary.
 
 [Quick Start](#installation) | [Docs](docs/README.md) | [Safety](docs/safety-policy-and-execution.md) | [Architecture](docs/system-architecture.md) | [Contributing](CONTRIBUTING.md) | [License](LICENSE)
 
@@ -47,7 +47,8 @@ policy and approval services, a central local ledger, and a local web dashboard
 for review.
 
 It is not an autonomous trading bot. Natural-language answers do not become
-broker actions. Live broker adapters are not shipped in the initial core.
+broker actions. The core ships paper execution by default; live broker support
+comes only from installed, reviewed providers and explicit live gates.
 
 ---
 
@@ -58,10 +59,11 @@ broker actions. Live broker adapters are not shipped in the initial core.
 | Codex-native harness | Generates a Codex workspace with `head-manager`, nine fixed subagents, role prompts, skills, hooks, project MCP config, and a local `./tcx` wrapper. |
 | Django service plane | Web, Admin, API, CLI, MCP, and generated hooks call shared application services for policy, orders, approvals, portfolio, audit, integrations, and research indexing. |
 | File-native research memory | Research markdown, role reports, source snapshots, versions, readiness labels, and handoff metadata stay readable in workspace files. |
+| Decision Workflow Alpha | Turn a natural-language investment idea into a Codex-native workflow plan and Decision Package under `trading/decisions/`. |
 | Fixed-role workflows | Specialist agents own bounded questions across fundamentals, technicals, news, macro, instruments, valuation, portfolio, risk, and execution. |
 | Approved action boundary | Actions are typed, role-scoped, policy-checked, approval-aware, duplicate-request checked, connection-gated, and audited. |
 | Local web dashboard | Review agents, skills, strategy skills, research markdown, Broker Center, Data Sources, order tickets, portfolio state, and activity at `127.0.0.1:48267`. |
-| Broker Center foundations | Register connector profiles, inspect capability profiles, run read-only paper sync, review instrument constraints, and reconcile portfolio state. |
+| Broker Center foundations | Connect provider-driven broker profiles, list installed providers, scaffold/register advanced connectors, inspect capability profiles, run account sync, review instrument constraints, and reconcile portfolio state. |
 | OrderTicket lifecycle | Draft, check, approve, submit, cancel, refresh, and inspect order tickets through central DB records and service-layer state transitions. |
 | Data Sources gate | Import external source discovery metadata, review available actions, scope role access, and block unsafe raw execution or secret paths by default. |
 | Improvement loop | Quality gates, postmortems, optional skills, strategy skills, strict artifact checks, and generated workspace smoke tests turn process gaps into durable improvements. |
@@ -138,8 +140,13 @@ boundaries rather than on black-box automation.
 - Deterministic executable boundary: every executable path follows
   a fixed requester, permission, policy, payload, approval, duplicate-request,
   connection, and audit sequence.
-- Safety-first broker posture: live broker execution is excluded; paper and
-  reviewed test/sandbox validation remain experimental local harness flows.
+- Safety-first broker posture: paper is built in; live broker execution requires
+  an installed provider plus workspace config, policy, environment opt-in,
+  approval, confirmation, idempotency, sync, and audit gates.
+- Broker control plane: TradingCodex stores connector state, capability
+  profiles, mapping review, approval, execution, reconciliation, and audit;
+  provider adapters absorb broker-specific REST, SDK, MCP, or manual interface
+  differences behind canonical service/MCP tools.
 
 ---
 
@@ -149,7 +156,7 @@ TradingCodex is designed around handoffs:
 
 ```text
 evidence -> analysis -> valuation -> portfolio fit -> risk review
-  -> draft order -> approval receipt -> approved non-live submission
+  -> draft order -> approval receipt -> approved service-gated submission
   -> connection result -> audit/postmortem
 ```
 
@@ -173,7 +180,7 @@ workflow has earned. Weak, stale, missing, or out-of-scope upstream work returns
 | Decision review | `valuation-analyst` | Valuation ranges, scenario assumptions, multiples, sensitivity, and decision-quality gaps. |
 | Portfolio | `portfolio-manager` | Portfolio fit, sizing, concentration, liquidity, opportunity cost, and draft order-ticket readiness. |
 | Risk | `risk-manager` | Downside, restricted-list checks, policy readiness, approval readiness, and approval receipts. |
-| Execution | `execution-operator` | Approved non-live submission through the TradingCodex service boundary only. |
+| Execution | `execution-operator` | Approved submission/cancel/status through the TradingCodex service boundary only; live requires all gates. |
 
 ---
 
@@ -187,9 +194,9 @@ workflow has earned. Weak, stale, missing, or out-of-scope upstream work returns
 | MCP | Agent/tool boundary with typed tools, role scopes, policy checks, approval checks, and audit. |
 | CLI | Local operator commands plus generated workspace `./tcx` wrapper behavior. |
 
-The baseline frontend uses Django templates, local static HTMX, and local
-static Alpine. There is no Node, bundler, React, or frontend build step in the
-core package.
+The baseline frontend uses Django templates, local static HTMX, and small plain
+JavaScript. There is no Node, bundler, React, or frontend build step in the core
+package.
 
 ---
 
@@ -205,8 +212,8 @@ TradingCodex blocks or constrains:
 - duplicate approved-order submissions
 - raw secrets in workspace files, prompts, API responses, MCP responses, audit
   payloads, generated docs, or shell output
-- unsupported live execution for crypto, macro, options, credit, FX, rates,
-  commodities, or other instruments
+- unsupported live execution through any provider, instrument, account, or
+  policy posture that has not passed the explicit live gate
 
 TradingCodex is research, workflow, and execution-guardrail tooling. It is not
 financial, investment, legal, tax, or regulatory advice, and it does not
@@ -219,9 +226,9 @@ provide investment recommendations or guarantee returns.
 | Status | Milestone |
 | --- | --- |
 | Shipped | Generated Codex workspace, fixed role roster, project MCP config, Django service plane, local web dashboard, Admin, Ninja API, file-native research memory, component registry, policy/audit primitives. |
-| Current `0.2.x` | Central-DB `OrderTicket` rewrite, Broker Center foundations, Data Sources gate, role-scoped actions, non-live execution lifecycle, and Python `>=3.11,<3.15` support. |
-| Next | Deeper validation scenarios, richer connector capability profiles, stronger generated-workspace smoke coverage, and improved artifact quality tooling. |
-| Future | Separately governed verified adapters, hosted/managed services, enterprise policy/compliance packs, and live broker support only after explicit product, policy, adapter, and validation work. |
+| Current `0.2.x` | Central-DB `OrderTicket` rewrite, provider-driven Broker Center foundations, Data Sources gate, role-scoped actions, live-gated execution lifecycle, and Python `>=3.11,<3.15` support. |
+| Next | Codex-native Decision Packages, deeper validation scenarios, richer provider capability profiles, stronger generated-workspace smoke coverage, and improved artifact quality tooling. |
+| Future | Separately governed verified adapters, hosted/managed services, enterprise policy/compliance packs, and broker-specific live providers only after explicit product, policy, adapter, and validation work. |
 
 ---
 

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/docs/README.md

@@ -25,6 +25,7 @@ reference, then follow the topic-specific files for implementation-level rules.
 | [improvement-loop.md](./improvement-loop.md) | Improvement taxonomy: workflow quality, research memory, file-native skill proposals, postmortems, validation feedback | Quality gates, learning loops, postmortems, skill proposal/projection, or validation feedback behavior changes |
 | [product-direction.md](./product-direction.md) | Product definition, target users, goals, non-goals, scope posture, current defaults | Product direction, release scope, default runtime, product language, or live-execution posture changes |
 | [financial-workflow-references.md](./financial-workflow-references.md) | Research-backed finance workflow and non-expert UX principles for workflow handoffs and role outputs | User-facing workflow intake, suitability/profile context, plain-English output, or professional finance method framing changes |
+| [investment-decision-quality-prd.md](./investment-decision-quality-prd.md) | PRD for vague-prompt routing, Decision Quality Spine, forecast discipline, scenario reasoning, data QC, and anti-overfit validation | Investment-analysis quality, forecasting, decision-support routing, shared decision-quality skills, or forecast/readiness artifact contracts change |
 | [system-architecture.md](./system-architecture.md) | Django modular monolith, central DB, app boundaries, service layer, core models, runtime planes | Django apps, DB ownership, service-layer use cases, model ownership, or runtime topology changes |
 | [interfaces-and-surfaces.md](./interfaces-and-surfaces.md) | Product web, Django Admin, Django Ninja API, MCP endpoint, CLI, generated `./tcx` wrapper | User/admin/API/MCP/CLI surface changes, route changes, or callable tool changes |
 | [safety-policy-and-execution.md](./safety-policy-and-execution.md) | Guardrail taxonomy, policy checks, approvals, idempotency, execution lifecycle, blocked actions | Policy, permissions, approvals, adapters, execution, restricted list, secret handling, or risk gates change |
@@ -57,8 +58,8 @@ reference, then follow the topic-specific files for implementation-level rules.
 | Django apps, models, service-layer contracts, or DB ownership | `system-architecture.md` |
 | Product web, Admin, REST, MCP, CLI, or wrapper behavior | `interfaces-and-surfaces.md` |
 | Guardrails, policy, permission, approval, execution, adapter, or secret boundary | `guardrails.md`, `safety-policy-and-execution.md`, `core-concepts-and-rules.md` |
-| Subagent roster, role responsibilities, skills, strategy behavior, workflow routing, or information barriers | `roles-skills-and-workflows.md`, `core-concepts-and-rules.md` |
-| Research memory, artifacts, exports, source snapshots, report readiness, or postmortem learning | `improvement-loop.md`, `research-memory-and-artifacts.md` |
+| Subagent roster, role responsibilities, skills, strategy behavior, workflow routing, decision-quality routing, or information barriers | `roles-skills-and-workflows.md`, `investment-decision-quality-prd.md`, `core-concepts-and-rules.md` |
+| Research memory, artifacts, exports, source snapshots, forecast ledgers, report readiness, or postmortem learning | `improvement-loop.md`, `research-memory-and-artifacts.md`, `investment-decision-quality-prd.md` |
 | Generated workspace structure, templates, hooks, bootstrap, or MCP config | `generated-workspaces.md` |
 | Test coverage or validation commands | `validation-and-test-plan.md` |
 | PyPI/TestPyPI release, CI/CD, or package distribution boundary | `deployment.md`, `product-direction.md` |

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/docs/components.md

@@ -38,13 +38,14 @@ paths clear.
 | `investment-request-routing` | Classifies user intent and activates fixed-role workflows. | `guardrail.guidance`, `improvement.workflow_quality` |
 | `fixed-role-dispatch` | Maintains head-manager, fixed subagent routing, and no-overlap handoff boundaries. | `guardrail.guidance`, `guardrail.information_barrier`, `improvement.workflow_quality` |
 | `research-memory` | Stores source-aware research artifacts, versions, snapshots, and exports. | `improvement.research_memory` |
-| `workflow-quality-gates` | Defines lane selection, handoff acceptance, artifact readiness, claim discipline, and synthesis gates. | `guardrail.guidance`, `improvement.workflow_quality` |
-| `artifact-quality-contract` | Evaluates workspace artifacts for source/as-of posture, claim tags, handoff state, confidence, missing evidence, and next-recipient routing metadata. | `guardrail.guidance`, `improvement.workflow_quality`, `improvement.research_memory` |
+| `workflow-quality-gates` | Defines lane selection, Decision Quality Spine, handoff acceptance, artifact readiness, claim discipline, and synthesis gates. | `guardrail.guidance`, `improvement.workflow_quality` |
+| `decision-package` | Wraps workflow plans, artifact paths, profile gaps, blocked actions, and next steps in Codex-readable workspace markdown. | `guardrail.guidance`, `improvement.workflow_quality`, `improvement.research_memory` |
+| `artifact-quality-contract` | Evaluates workspace artifacts and forecast ledgers for source/as-of posture, claim tags, handoff state, confidence, missing evidence, and next-recipient routing metadata. | `guardrail.guidance`, `improvement.workflow_quality`, `improvement.research_memory` |
 | `context-efficiency-contract` | Keeps workflows bounded through compact briefs, artifact references, context summaries, source snapshot IDs, targeted full-artifact reads, and `subagents context-audit` validation. | `guardrail.guidance`, `guardrail.information_barrier`, `improvement.workflow_quality`, `improvement.context_efficiency` |
 | `responsibility-boundary-contract` | Separates durable role identity, tool permissions, skill procedures, artifact contracts, and projection ownership so changes stay local. | `guardrail.guidance`, `guardrail.information_barrier`, `improvement.workflow_quality`, `improvement.skill_evolution` |
 | `external-data-source-gate` | Keeps external evidence read-only and source-aware. | `guardrail.guidance`, `improvement.workflow_quality` |
 | `external-mcp-proxy-gate` | Registers external MCP connections, imports metadata, classifies risk, manages lifecycle/review state, and blocks unsafe direct connection paths. | `guardrail.enforcement`, `guardrail.information_barrier` |
-| `broker-center` | Normalizes native broker connector profiles, read-only account discovery, sync runs, instrument constraints, and order-translation previews. | `guardrail.enforcement`, `improvement.workflow_quality` |
+| `broker-center` | Acts as the local broker control plane for connector state, capability profiles, source drift, read-only account discovery, sync runs, mapping review, reconciliation, and service-gated execution. | `guardrail.enforcement`, `improvement.workflow_quality` |
 | `secret-wall` | Blocks raw broker secrets from workspace files, prompts, shell paths, and role context. | `guardrail.enforcement`, `guardrail.information_barrier` |
 | `policy-and-restricted-list` | Evaluates principals, capabilities, explicit deny rules, restricted symbols, and limits. | `guardrail.enforcement` |
 | `approval-gate` | Validates order tickets, JSON order inputs, and approval receipts before execution-sensitive action. | `guardrail.enforcement` |

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/docs/core-concepts-and-rules.md

@@ -59,7 +59,7 @@ Use [harness.md](./harness.md) for the top-level model,
 | Plane | Responsibility | Source document |
 | --- | --- | --- |
 | Codex control plane | Agent behavior, workflow, tool surface, prompts, skills, hooks, and Codex-level guidance | [roles-skills-and-workflows.md](./roles-skills-and-workflows.md), [generated-workspaces.md](./generated-workspaces.md) |
-| Django service plane | Durable policy/order/portfolio/audit/harness/integration logic, product web, Admin, Ninja, MCP HTTP endpoint, and research file indexing | [system-architecture.md](./system-architecture.md), [interfaces-and-surfaces.md](./interfaces-and-surfaces.md) |
+| Django service plane | Durable policy/order/portfolio/audit/harness/integration logic, product web, Admin, Ninja, stdio MCP bridge, and research file indexing | [system-architecture.md](./system-architecture.md), [interfaces-and-surfaces.md](./interfaces-and-surfaces.md) |
 | Workspace system plane | Generated schemas, policy exports, MCP wrappers, research markdown, readable artifacts, audit directories | [generated-workspaces.md](./generated-workspaces.md), [research-memory-and-artifacts.md](./research-memory-and-artifacts.md) |
 
 Workspace identity is the Codex workbench identity. Research handoffs are
@@ -76,7 +76,7 @@ portfolio state or execution policy.
 | --- | --- | --- | --- |
 | Guidance guardrail | Reduce risky behavior before it reaches execution. | `AGENTS.md`, skills, role prompts, hooks, checklists | [roles-skills-and-workflows.md](./roles-skills-and-workflows.md) |
 | Enforcement guardrail | Deterministically block risky action completion. | permissions, policy, approval checks, MCP allowlists | [safety-policy-and-execution.md](./safety-policy-and-execution.md) |
-| Information barrier | Control knowledge and file-access flow. | role file walls, restricted list, secret wall | [roles-skills-and-workflows.md](./roles-skills-and-workflows.md), [safety-policy-and-execution.md](./safety-policy-and-execution.md) |
+| Information barrier | Control knowledge and file-access flow. | role skill-source boundaries, restricted list, secret wall | [roles-skills-and-workflows.md](./roles-skills-and-workflows.md), [safety-policy-and-execution.md](./safety-policy-and-execution.md) |
 | Improvement loop | Standardize artifact quality, learn from outcomes, and improve future workflow behavior. | workflows, quality gates, readiness labels, research memory, file-native skill proposals, postmortems, validation feedback | [improvement-loop.md](./improvement-loop.md), [research-memory-and-artifacts.md](./research-memory-and-artifacts.md), [roles-skills-and-workflows.md](./roles-skills-and-workflows.md) |
 
 ## Role Boundary Snapshot
@@ -91,7 +91,7 @@ subagents. Detailed responsibilities live in
 | analyst roles | research, evidence, valuation, market/instrument context | order approval, execution, secret read |
 | `portfolio-manager` | portfolio fit and draft order ticket | self-approval, execution, arbitrary policy change |
 | `risk-manager` | risk review, policy review, approval receipt | order drafting, execution, arbitrary policy change |
-| `execution-operator` | submit approved non-live orders through the TradingCodex service boundary | raw broker API, secret read, policy change |
+| `execution-operator` | submit/cancel approved orders through the TradingCodex service boundary; live only after all gates pass | raw broker API, secret read, policy change |
 
 Handoff states are `accepted`, `revise`, `blocked`, or `waiting`. Only accepted
 artifacts move downstream. `head-manager` may synthesize accepted outputs and

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/docs/deployment.md

@@ -5,8 +5,9 @@ TradingCodex is distributed as a Python package on PyPI. The package name is
 
 TradingCodex is local-first software. A PyPI release ships the CLI, Django
 service plane, generated workspace templates, Admin/Web templates, static
-assets, and MCP gateway code. It does not deploy a hosted service and it does
-not ship live broker execution.
+assets, and MCP gateway code. It does not deploy a hosted service. Core ships
+paper execution by default; broker-specific live execution requires installed,
+reviewed providers and explicit live gates.
 
 ## Release Policy
 
@@ -18,9 +19,9 @@ application-service surfaces are the supported contract.
 
 Execution status for this release line:
 
-- live broker execution is excluded
-- paper and validation-only execution code remains in the package for local harness tests
-- non-live execution is experimental and not production trading
+- paper execution is built in
+- validation and live-capable provider code must be installed/reviewed before use
+- live submission is disabled by default and requires config, policy, environment, adapter, health, approval, confirmation, idempotency, sync, and audit gates
 - execution MCP tools must stay behind policy, approval, duplicate-request,
   connection, and audit checks
 
@@ -140,7 +141,7 @@ python3.11 -m venv /tmp/tcx-testpypi
 /tmp/tcx-testpypi/bin/pip install \
   --index-url https://test.pypi.org/simple/ \
   --extra-index-url https://pypi.org/simple/ \
-  tradingcodex==0.2.5
+  tradingcodex==0.2.7
 rm -rf /tmp/tcx-testpypi-smoke
 mkdir -p /tmp/tcx-testpypi-smoke
 cd /tmp/tcx-testpypi-smoke
@@ -156,8 +157,8 @@ available on TestPyPI.
 Before pushing the release tag:
 
 - verify `pyproject.toml` version is the intended release version
-- verify `README.md` describes execution as experimental
-- verify docs mention that live broker execution is excluded
+- verify `README.md` describes execution as service-gated
+- verify docs mention that live broker execution requires installed providers and explicit gates
 - run local build verification
 - run a TestPyPI release when packaging changed
 
@@ -169,7 +170,7 @@ After the PyPI workflow completes:
 
 ```bash
 python3.11 -m venv /tmp/tcx-pypi
-/tmp/tcx-pypi/bin/pip install tradingcodex==0.2.5
+/tmp/tcx-pypi/bin/pip install tradingcodex==0.2.7
 rm -rf /tmp/tcx-pypi-smoke
 mkdir -p /tmp/tcx-pypi-smoke
 cd /tmp/tcx-pypi-smoke
@@ -253,7 +254,12 @@ Use PEP 440 versions:
   context, build-mode updates, and connector scaffold workflow
 - `0.2.5` for packaged web static assets and startup service mismatch notices
   reaching head-manager compact context
-- later patch releases for compatible fixes after `0.2.5`
+- `0.2.6` for provider-driven Broker Center foundations, live-gated provider
+  execution paths, runtime surface simplification, and stricter subagent skill
+  boundaries after `0.2.5`
+- `0.2.7` for Codex-native decision packages and investment decision quality
+  spine improvements after `0.2.6`
+- later patch releases for compatible fixes after `0.2.7`
 - pre-releases such as `0.3.0a1`, `0.3.0b1`, or `0.3.0rc1` when preparing
   the next minor contract
 

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/docs/generated-workspaces.md

@@ -101,6 +101,11 @@ Generated workspaces contain:
 - no-overlap handoff contract: each role owns its specialist question, downstream roles consume accepted artifacts, and missing/stale/weak upstream work returns `revise`, `blocked`, or `waiting` instead of being silently redone by another role
 - closed selected team: hook/starter-prompt selected roles are binding for the current lane; research-only prompts do not add portfolio, risk, approval, or execution roles for precautionary coverage
 - negated scope routing: phrases such as "no valuation", "no order", and "no trading" remove those actions or roles from dispatch selection
+- broad public-equity prompts such as "Analyze NVDA" default to deep thesis
+  review with fundamental, technical, news, and valuation roles unless explicit
+  constraints narrow the team first
+- compact Decision Quality Spine flags in hook context for decision quality,
+  forecast contract, profile gate, anti-overfit, and deep thesis default
 - no full-history fixed-role spawn: fixed `agent_type` subagents receive compact assignment envelopes without full-history forking on the first attempt
 - subagent hook isolation: `UserPromptSubmit` auto-routing is ignored for fixed subagent contexts so subagent briefs cannot overwrite main-agent routing state or create recursive dispatch pressure
 - main-to-subagent briefs are assignment envelopes, not role manuals: they carry the current task, original request, explicit constraints, workflow consent posture, research artifact language, lane, artifact target, compact context summary, request-specific out-of-scope items, and return contract without repeating long method/source/guardrail checklists or pasting full artifacts
@@ -122,14 +127,16 @@ Generated workspaces contain:
 - fixed subagent `nickname_candidates` set to a single item matching the exact role `name`
 - fixed subagent identities kept in `.codex/agents/*.toml` `developer_instructions`, as required by Codex custom agent files
 - project-local additional agent instructions under `.tradingcodex/agent-instructions/<role>.md`; projection appends them after generated default instructions for `head-manager` and fixed subagents
-- twenty-four core repo skills across project-scope mainagent skills and subagent skill directories, each with `SKILL.md` frontmatter for document metadata and `agents/openai.yaml` UI metadata
+- twenty-three core repo skills across project-scope mainagent skills and subagent skill directories, each with `SKILL.md` frontmatter for document metadata and `agents/openai.yaml` UI metadata
+- shared decision-quality skill bundles for forecasting discipline, thesis
+  scenario trees, numeric data QC, and anti-overfit validation
 - standalone `strategy-*` skills under `.agents/skills/strategy-*` for user-approved agent-readable investment strategies, created through `strategy-creator`, CLI, API, or service-layer flows and exposed to the root `head-manager` through the strategy marker block in `.codex/config.toml`; Django web lists and previews them read-only
-- file-native agent/skill projection: role skill state is expressed in `.codex/agents/*.toml`, `.agents/skills/*`, `.tradingcodex/subagents/skills/*`, `.codex/config.toml`, `.tradingcodex/mainagent/skill-change-proposals/*.yaml`, and `.tradingcodex/generated/*.json`, not Django skill DB tables
+- file-native agent/skill projection: head-manager and strategy skills live under `.agents/skills/*`, role-owned subagent skills live under `.tradingcodex/subagents/skills/*`, and role TOML embeds the allowed role skill source list; state is expressed in `.codex/agents/*.toml`, `.codex/config.toml`, `.tradingcodex/mainagent/skill-change-proposals/*.yaml`, and `.tradingcodex/generated/*.json`, not Django skill DB tables
 - optional subagent skills are created, updated, activated, archived, deleted, and validated through the shared application service used by `head-manager`, CLI, API, and Django web
 - information-barrier policies
 - order/approval schemas
 - restricted-list policy
-- paper and validation-only non-live adapters
+- built-in paper provider plus provider-driven validation/live gates
 - audit directories
 - central local SQLite service access through `~/.tradingcodex/state/tradingcodex.sqlite3`
 - workspace identity through `.tradingcodex/workspace.json`
@@ -139,6 +146,7 @@ Generated workspaces contain:
 - generated indexes under `.tradingcodex/generated/`, including
   `module-lock.json`, `capability-index.json`, `component-index.json`,
   `agent-index.json`, `skill-index.json`, and `projection-manifest.json`
+- append-only forecast ledger directory at `trading/forecasts/`
 
 Workspace template modules are deployment projections. Harness component
 ownership comes from the Python component registry and is exported into
@@ -250,9 +258,10 @@ Generated permission profiles allow network access for public evidence
 gathering, such as filings, disclosures, news, web sources, and market-data
 references. They still deny workspace secret paths and do not authorize direct
 broker APIs, broker-specific Codex MCP servers, approval bypass, or execution.
-Broker APIs are attached through native TradingCodex connector profiles using
-canonical MCP tools such as `list_broker_connector_templates`,
-`register_broker_connector`, `get_broker_capability_profile`,
+Broker APIs are attached through provider-driven TradingCodex connector profiles
+using canonical MCP tools such as `list_broker_adapter_providers`,
+`scaffold_broker_connector`, `register_broker_connector`,
+`validate_broker_connector_build`, `get_broker_capability_profile`,
 `get_broker_instrument_constraints`, and `preview_order_translation`.
 
 Generated Codex config declares the TradingCodex home directory, normally
@@ -331,8 +340,9 @@ Build mode is per workspace and explicit:
 - `./tcx mode set build --reason "<reason>"`
 - `./tcx mode set operate`
 
-Build mode may update TradingCodex, templates, and broker/API adapter
-scaffolds. It never enables live execution. Update recommendations are scoped
+Build mode may update TradingCodex, templates, and broker/API provider
+scaffolds, including live-capable provider code. It never submits live orders;
+live submission remains behind the service gates. Update recommendations are scoped
 to the new-conversation health pass, not every user turn. If the user declines
 update prompts, `head-manager` records the TradingCodex home preference file,
 normally `~/.tradingcodex/preferences/update.json`, with
@@ -340,9 +350,20 @@ normally `~/.tradingcodex/preferences/update.json`, with
 recommend automatic workspace updates unless the user removes or changes that
 flag, or explicitly asks for an update.
 
-Connector scaffold commands accept short aliases such as `binance`, `kis`,
-`한투`, `upbit`, and `alpaca`; the generated connector profile still records
-the canonical template ID.
+Connector onboarding is connect-first: `tcx connectors connect <broker>` wraps
+provider discovery, scaffold, registration, validation, and plain status output.
+Advanced scaffold/register/validate commands remain available. If the requested
+provider is not installed, the generated connector profile records
+`provider_development_required` instead of pretending the broker is already
+supported.
+
+Broker provider build work is separate from the running operate server. A
+generated workspace may already have TradingCodex MCP autostarting the Django
+service; provider file changes must not be treated as hot-loaded live execution
+authority. Connector profiles record provider source hashes, status calls report
+`service_restart_required` when source changed after registration, and live
+execution remains blocked until the service is restarted and the connector is
+revalidated.
 
 ## Hooks
 
@@ -364,7 +385,7 @@ enforcement.
 - execution negation routing such as "no order" and "no trading"
 - strategy authoring prompts remain in `strategy-creator`/strategy CRUD scope
   instead of auto-dispatching fixed investment subagents
-- connector implementation prompts such as "binance 붙여줘" or "connect KIS"
+- connector implementation prompts such as "connect this broker"
   route to the `connector_build` lane and `$tcx-build`, not investment
   dispatch
 - secret-only routing: credential, token, password, broker-key, or `.env`

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/docs/guardrails.md

@@ -69,7 +69,7 @@ Information barriers cover:
 - execution walls
 - policy walls
 - secret walls
-- role file boundaries
+- role skill-source boundaries
 - role-specific MCP allowlists
 - generated subagent permission profiles
 

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/docs/harness.md

@@ -50,6 +50,7 @@ TradingCodex Harness
 | Guardrails | Reduce, restrict, or block risky actions through guidance, enforcement, and information barriers. |
 | Improvement | Raise workflow quality through no-overlap handoff contracts, quality gates, artifact readiness, research memory, postmortems, and test feedback. |
 | Approved action boundary | Keep executable actions behind policy, approval, duplicate-request, connection, and audit checks. |
+| Decision packages | Keep investment ideas Codex-native by packaging workflow plans, artifact paths, profile gaps, blocked actions, and next allowed actions as workspace markdown. |
 | Provenance | Record which workspace and role produced or requested work without making workspaces separate ledgers. |
 | Profiles | Separate paper portfolio/account/strategy state from workspace identity. |
 | Components | Provide the developer-facing maintenance map for implementation surfaces, dependencies, capabilities, tags, and validation. |
@@ -112,6 +113,13 @@ It is a tag and review lens applied to components.
 Improvement does not authorize execution. A high-quality report still needs the
 guardrail path before any draft, approval, or non-live connection use.
 
+Decision Quality Spine is part of Improvement, not a new monolithic workflow.
+It adds shared expectations for intent normalization, scenario reasoning,
+forecast permission, numeric data QC, anti-overfit review, challenge review,
+readiness labels, and append-only forecast ledger records. The spine applies
+inside the selected lane and selected team only; it never widens role authority,
+MCP access, approval, execution, broker, or secret boundaries.
+
 ## Interface Implications
 
 The product web app should make the harness usable through a workflow-planner

{tradingcodex-0.2.5 → tradingcodex-0.2.7}/docs/interfaces-and-surfaces.md

@@ -1,7 +1,7 @@
 # Interfaces And Surfaces
 
 This document owns the behavior of TradingCodex product web, Django Admin,
-Django Ninja API, Django-hosted MCP, CLI, and generated workspace wrappers.
+Django Ninja API, stdio MCP, CLI, and generated workspace wrappers.
 
 ## Interface Rule
 
@@ -57,8 +57,8 @@ of the primary product navigation:
 - `/policy/` restricted list and policy decision review
 - `/activity/` MCP call ledger, audit events, and workflow activity
 
-The product web app uses Django templates, local static HTMX, and local static
-Alpine. There is no Node, bundler, React, or frontend build step in the
+The product web app uses Django templates, local static HTMX, and small plain
+JavaScript. There is no Node, bundler, React, or frontend build step in the
 baseline. Its visual language follows a compact dark dashboard style inspired
 by shadcn `new-york` components, implemented with vanilla CSS over Django
 templates rather than React or Tailwind.
@@ -232,8 +232,7 @@ workspace provenance stay in the same approved action boundary.
 
 TradingCodex exposes the official Codex MCP path through project-scoped stdio:
 `tcx mcp stdio`. MCP is intentionally selected service-layer use cases, not an
-automatic REST mirror. The Django `/mcp` endpoint is retained only as a
-legacy/debug transport and is not the generated Codex workspace path.
+automatic REST mirror.
 
 Minimum MCP protocol surface:
 
@@ -364,8 +363,10 @@ Generated workspace wrapper commands:
 - `./tcx mode set build --reason "<reason>"`
 - `./tcx mode set operate`
 - `./tcx connectors status`
-- `./tcx connectors scaffold <template-or-alias> --broker-id <id>`
-- `./tcx connectors register <template-or-alias> --broker-id <id> --credential-ref <ref> --environment <paper|sandbox|testnet>`
+- `./tcx connectors providers`
+- `./tcx connectors connect <broker> [--provider <provider-id>] [--credential-ref <ref>] [--mode read-only|validation|live-request]`
+- `./tcx connectors scaffold <broker-id> [--provider <provider-id>] [--credential-ref <ref>] [--environment <env>]`
+- `./tcx connectors register --provider <provider-id> --broker-id <id> --credential-ref <ref> [--environment <env>]`
 - `./tcx connectors validate <broker-id>`
 - `./tcx workspace status|list`
 - `./tcx profile status|list|create|select|update`
@@ -373,9 +374,9 @@ Generated workspace wrapper commands:
 - `./tcx subagents prompt [--json|--explain] "<request>"`
 - `./tcx skills optional list|inspect|create|update|activate|archive|delete`
 
-Short aliases such as `binance`, `kis`, `한투`, `upbit`, and `alpaca` resolve
-to canonical connector templates while generated profiles keep the canonical
-template ID.
+Connector setup is provider-first. Core ships the `paper` provider only; a
+named broker request routes to `$tcx-build` to install or develop a reviewed
+provider, then registration stores only provider metadata and `credential_ref`.
 - `./tcx strategies list|inspect|create|update|activate|archive|delete`
 - `./tcx validate order <path>`
 - `./tcx approve <path>`