tradingcodex 0.2.5__tar.gz → 0.2.6__tar.gz

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: tradingcodex
-Version: 0.2.5
+Version: 0.2.6
 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.
 
 ---
 
@@ -92,7 +93,7 @@ broker actions. Live broker adapters are not shipped in the initial core.
 | 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 +170,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 +186,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 +210,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 +224,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 +242,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 +256,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 | 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.6}/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.
 
 ---
 
@@ -61,7 +62,7 @@ broker actions. Live broker adapters are not shipped in the initial core.
 | 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 +139,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 +155,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 +179,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 +193,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 +211,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 +225,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 | 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.6}/docs/components.md

@@ -44,7 +44,7 @@ paths clear.
 | `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.6}/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.6}/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.6
 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.6
 rm -rf /tmp/tcx-pypi-smoke
 mkdir -p /tmp/tcx-pypi-smoke
 cd /tmp/tcx-pypi-smoke
@@ -253,7 +254,10 @@ 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`
+- later patch releases for compatible fixes after `0.2.6`
 - 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.6}/docs/generated-workspaces.md

@@ -122,14 +122,14 @@ 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
+- nineteen 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
 - 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`
@@ -250,9 +250,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 +332,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 +342,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 +377,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.6}/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.6}/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>`

{tradingcodex-0.2.5 → tradingcodex-0.2.6}/docs/product-direction.md

@@ -58,8 +58,8 @@ guidance emitted by the product should remain English.
 | Python | Use the current supported Python line defined in `pyproject.toml` and release docs. |
 | Django | Use the latest LTS-oriented Django service plane, currently Django 5.2.x. |
 | Database | Default to central local SQLite; design models so PostgreSQL remains viable later. |
-| Frontend | Use Django templates, local static HTMX, and local static Alpine; no Node, bundler, React, or frontend build step in the baseline. |
-| MCP | Host MCP inside Django and provide stdio bridge support for Codex environments that require stdio. |
+| Frontend | Use Django templates, local static HTMX, and small plain JavaScript; no Node, bundler, React, or frontend build step in the baseline. |
+| MCP | Provide project-scoped stdio bridge support for Codex environments. |
 | Deployment | Local-first. PyPI installs the local package; initial scope does not provide a hosted service. |
 
 ## Goals In Detail
@@ -81,7 +81,7 @@ guidance emitted by the product should remain English.
 
 | Non-goal | Reason |
 | --- | --- |
-| Built-in live broker execution | The initial core must prove policy, approval, duplicate-request, connection, and audit behavior before live broker support. |
+| Built-in named live broker execution | Core ships paper only; broker-specific live support is request-built provider work behind the TradingCodex broker control plane and must pass provider review, policy, approval, duplicate-request, connection, sync, and audit gates. |
 | Raw credential storage | Secrets do not belong in generated workspaces, prompt output, API responses, MCP responses, logs, or audit output. |
 | REST execution bypass | REST endpoints may validate or call service-layer use cases, but cannot bypass MCP/service execution rules. |
 | Product web orchestration | The web dashboard reviews state and previews workflow handoffs; it does not spawn subagents or perform investment analysis. |

{tradingcodex-0.2.5 → tradingcodex-0.2.6}/docs/roles-skills-and-workflows.md

@@ -43,7 +43,7 @@ artifact.
 | `valuation-analyst` | valuation range, scenario assumptions, market-implied expectations, sensitivity | accepted research artifacts and user-stated method constraints | valuation report with assumptions, sensitivity, confidence, and readiness for portfolio/risk review |
 | `portfolio-manager` | portfolio fit, sizing context, concentration, liquidity, opportunity cost, draft order-ticket readiness | accepted research/valuation artifacts and portfolio state | portfolio report and, only when allowed, draft order-ticket readiness or draft ticket |
 | `risk-manager` | downside, restricted-list and policy readiness, limits, approval readiness, approval receipt | accepted portfolio/order artifacts, policy state, restricted-list state, audit evidence | risk/policy report, approval readiness state, approval receipt when allowed, or blocked reasons |
-| `execution-operator` | approved non-live order-ticket submission through the TradingCodex service boundary | approved order ticket, matching approval receipt, policy allow state | execution result, MCP response, audit reference, or rejected/blocked reasons |
+| `execution-operator` | approved submit/cancel/status through the TradingCodex service boundary; live only when every live gate passes | approved order ticket, matching approval receipt, policy allow state | execution result, MCP response, audit reference, or rejected/blocked reasons |
 
 Downstream roles handle weak upstream work by returning a revision request or
 `blocked` readiness state. They do not repair missing upstream analysis inside
@@ -100,7 +100,7 @@ they are not required before `head-manager` routes the work.
 | --- | --- |
 | General investment request, such as "Analyze Apple stock" | `UserPromptSubmit` injects compact auto-dispatch context with lane, selected team, blocked actions, and the persisted prompt-gate path; `head-manager` dispatches or reuses selected subagents before analysis. |
 | Explicit `$tcx-workflow` request | The workflow skill becomes the primary manual-control orchestrator and dispatches selected subagents. |
-| Connector build request, such as "binance 붙여줘" or "connect KIS API" | Route to the `connector_build` lane and `$tcx-build`; scaffold/register/validate read/test connector metadata only, without investment dispatch or live execution. |
+| Broker/provider build request, such as "connect this broker" | Route to the `connector_build` lane and `$tcx-build`; connect/scaffold/register/validate provider metadata without investment dispatch or live submission. |
 | Runtime/server request, such as "open dashboard" or "check TradingCodex status" | Route to `$tcx-server`; report service/MCP/update posture and use CLI recovery commands without changing execution authority. |
 | Explicit subagent/parallel/delegated request | `UserPromptSubmit` records the explicit activation source; the skill checks existing subagent state before creating/reusing sessions. |
 | Strategy authoring request, such as "Create a quality income strategy" | Do not auto-dispatch investment subagents. Route through `strategy-creator`, CLI, API, or service-layer flows so the strategy skill is created and projected as a root/head-manager strategy entry. Django web previews strategies read-only. |
@@ -147,7 +147,7 @@ boundary, approval requirements, or information barriers.
 | --- | --- | --- |
 | Broad analysis such as "Analyze Apple stock" | auto-dispatch or reuse selected subagents, then wait for outputs before synthesis | Direct business/price/news/recommendation analysis |
 | Explicit workflow request such as "$tcx-workflow analyze Apple" | Spawn selected team or reuse active/completed roles, wait for outputs, then synthesize | Analyze without dispatch |
-| Connector build request such as "binance 붙여줘" | Check full-access plus TCX build mode, scaffold/register/validate connector metadata through `$tcx-build`, and keep `live_order` disabled | Dispatch investment subagents, ask for raw secrets, or expose raw broker SDK tools |
+| Broker/provider build request | Check full-access plus TCX build mode, connect/scaffold/register/validate provider metadata through `$tcx-build`, and keep live submission inside service gates | Dispatch investment subagents, ask for raw secrets, or expose raw broker SDK tools |
 | Decision support such as "Should I buy?" | Dispatch analyst/valuation/portfolio/risk team and explain required artifacts/gates | Offer buy/sell opinion without subagent output |
 | Dispatch unavailable, role routing unverified, or dispatch failed | Provide `waiting_for_subagent_dispatch` state and task briefs only | Switch to "I will analyze it myself" |
 | Subagent artifacts exist | Summarize role outputs, conflicts, confidence/missing evidence, and next allowed action | Override subagent evidence with unsupported certainty |
@@ -155,9 +155,12 @@ boundary, approval requirements, or information barriers.
 
 ## Skills And Context
 
-Repo-local skills live under `.agents/skills/*` so they are discoverable at the
-workspace level. TradingCodex treats role-owned skills as an ownership contract
-and config boundary.
+Head-manager and strategy skills live under `.agents/skills/*` so they are
+discoverable to the root workspace coordinator. Role-owned subagent skills live
+under `.tradingcodex/subagents/skills/*`; each fixed-role TOML file projects
+only that role's allowed skill source list into developer instructions so a
+custom subagent can apply its own procedures without importing root, strategy,
+or out-of-role skill files.
 
 Instruction/skill separation:
 
@@ -229,11 +232,31 @@ Head-manager skill responsibilities:
 | --- | --- |
 | `tcx-workflow` | compact workflow routing, selected-team dispatch/reuse, handoff quality states, and synthesis after accepted artifacts |
 | `tcx-server` | startup health, local dashboard URL guidance, explicit user-requested dashboard opening, Codex restart guidance, TradingCodex MCP setup, update-status explanation, read-only broker/status inspection, and service troubleshooting without granting execution authority |
-| `tcx-build` | full-access plus TCX-build-mode gated self-update, template/harness edits, broker/API connector scaffold/register/validate flows, credential-ref handling, and live-order blocking |
+| `tcx-build` | full-access plus TCX-build-mode gated self-update, template/harness edits, broker/API provider connect/scaffold/register/validate flows, credential-ref handling, and live-submit blocking outside service gates |
 | `external-data-source-gate` | read-only external evidence-source constraints and External MCP Gate honesty |
 | `strategy-creator` | create, update, validate, and activate user-approved `strategy-*` skills as strategy library entries without granting policy, approval, execution, MCP, or role-boundary authority |
 | `postmortem` | audit-backed process review and improvement proposals after failures, thesis changes, rejected orders, or executions |
 
+## Broker Control Plane
+
+TradingCodex is the local broker control plane, not a bundled collection of
+broker SDK shortcuts. Codex may prepare a broker connector from natural
+language, but the server owns connector state, provider capability profiles,
+mapping review, account sync, order tickets, approvals, idempotency, broker
+order status, reconciliation, and audit.
+
+Broker-specific REST, SDK, MCP, CSV, or manual interfaces belong behind
+provider adapters. The server calls only the small canonical broker contract for
+health, account/cash/position reads, constraints, preview/validation, and
+reviewed live submit/cancel/status methods.
+
+`execution-operator` uses TradingCodex MCP canonical tools such as
+`submit_approved_order`, `cancel_approved_order`, `refresh_broker_order_status`,
+`get_order_ticket`, and `run_order_checks`. It never calls broker APIs, broker
+SDKs, shell scripts, or broker-specific MCP tools directly. If a broker is MCP
+backed, the reviewed broker MCP mapping stays behind the TradingCodex service
+execution path.
+
 ## Strategy Skills
 
 Output language precedence is:
@@ -299,7 +322,7 @@ user or web request -> shared service validation -> workspace file edit -> TOML
 
 Codex-visible state is file-native: `.codex/agents/*.toml`,
 `.agents/skills/*`, `.tradingcodex/subagents/skills/*`,
-`.codex/config.toml`, and
+`.codex/config.toml`, role-projected skill source blocks, and
 `.tradingcodex/generated/projection-manifest.json`. Django DB does not store
 skill proposals, role-skill assignments, optional skill CRUD state, or skill
 application audit state.
@@ -346,8 +369,8 @@ approval, or execution authority.
 Generated Codex permission profiles allow public web, filing, disclosure, news,
 and market-data network access for evidence gathering. Direct broker APIs,
 broker-specific Codex MCP servers, raw secrets, approval bypasses, and execution
-remain blocked by role instructions, file walls, TradingCodex MCP allowlists,
-and service-layer policy.
+remain blocked by role instructions, projected role skill-source boundaries,
+TradingCodex MCP allowlists, and service-layer policy.
 
 ## Hooks Are Guidance