tradingcodex 0.2.3__tar.gz → 0.2.5__tar.gz

{tradingcodex-0.2.3 → tradingcodex-0.2.5}/MANIFEST.in

@@ -9,5 +9,5 @@ recursive-include docs *
 recursive-include workspace_templates *
 recursive-include workspace_templates .*
 recursive-include tradingcodex_service/templates *
-recursive-include static *
+recursive-include tradingcodex_service/static *
 global-exclude *.py[cod]

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: tradingcodex
-Version: 0.2.3
+Version: 0.2.5
 Summary: Codex-native trading harness with a Django service plane and approved action boundary.
 Author: TradingCodex Authors
 License-Expression: Apache-2.0

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

@@ -140,7 +140,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.3
+  tradingcodex==0.2.5
 rm -rf /tmp/tcx-testpypi-smoke
 mkdir -p /tmp/tcx-testpypi-smoke
 cd /tmp/tcx-testpypi-smoke
@@ -169,7 +169,7 @@ After the PyPI workflow completes:
 
 ```bash
 python3.11 -m venv /tmp/tcx-pypi
-/tmp/tcx-pypi/bin/pip install tradingcodex==0.2.3
+/tmp/tcx-pypi/bin/pip install tradingcodex==0.2.5
 rm -rf /tmp/tcx-pypi-smoke
 mkdir -p /tmp/tcx-pypi-smoke
 cd /tmp/tcx-pypi-smoke
@@ -204,6 +204,30 @@ TradingCodex has two update layers:
   generated files, generated indexes, project MCP config, hook scripts, and
   central DB schema
 
+Generated workspace `./tcx update` normally refreshes through `uvx` first so
+stale recorded Python paths do not rewrite templates. In restricted Codex
+permissions, `head-manager` should not run the update itself because it rewrites
+protected `.codex` prompt/config/hook surfaces. When the package is already
+installed and Codex startup health reports `workspace_update_allowed=true`,
+`head-manager` should tell the user to switch to full access plus TradingCodex
+build mode, or run the workspace-only path from a terminal:
+
+```bash
+./tcx update --skip-refresh
+```
+
+`head-manager` may run the update directly only when
+`update_status.can_self_update=true`, which requires Codex full access,
+unexpired TradingCodex build mode, and an explicit user request. After a
+self-update it must stop and tell the user to fully restart Codex. The terminal
+path avoids package-cache or user-tool writes and keeps self-modifying `.codex`
+prompt/config/hook updates outside a restricted active Codex agent sandbox.
+Generated Codex config declares the bounded `~/.tradingcodex` writable root so
+central DB migrations, lock files, and update preferences can still work
+without disabling the sandbox when the active Codex surface honors
+project-scoped sandbox roots. If a package update is required first, the user
+should run the package-refresh command from a terminal instead.
+
 `tcx update` must preserve `.tradingcodex/workspace.json` identity fields,
 including `workspace_id` and active profile. It may overwrite generated paths
 owned by `workspace_templates/modules/*/files`, and it must not overwrite
@@ -225,7 +249,11 @@ Use PEP 440 versions:
 - `0.2.2` for dashboard startup behavior fixes after `0.2.1`
 - `0.2.3` for workflow-planner UX, fixed strategy authoring, profile-scoped
   ticket isolation, workspace-scoped transition audit, and startup/status fixes
-- later patch releases for compatible fixes after `0.2.3`
+- `0.2.4` for the operate/build/execution plane rewrite, compact startup
+  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`
 - pre-releases such as `0.3.0a1`, `0.3.0b1`, or `0.3.0rc1` when preparing
   the next minor contract
 

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

@@ -195,6 +195,28 @@ The generated `./tcx` wrapper special-cases `update` to prefer
 prevents an old recorded Python path from refreshing the workspace with stale
 template code.
 
+Inside a Codex-generated workspace, `head-manager` runs under a workspace
+permission profile. It can write workspace files and TradingCodex home state,
+but it should not update the generated harness itself: workspace update rewrites
+protected `.codex` prompt/config/hook surfaces and generated files that define
+the current agent. For already-installed packages, the wrapper supports a
+user-terminal workspace-only path:
+
+```bash
+./tcx update --skip-refresh
+```
+
+`--skip-refresh` uses the recorded Python/package and avoids the `uvx` refresh
+step. If startup health reports `update_status.workspace_update_allowed=true`,
+`head-manager` should tell the user to run
+`update_status.workspace_update_command` from their terminal. If startup health
+reports `update_status.package_update_required_first=true`, package refresh is
+also a user-terminal action, normally:
+
+```bash
+uvx --refresh --from tradingcodex tcx update .
+```
+
 ## Project-Scoped MCP Config
 
 Generated Codex workspaces render a project-scoped
@@ -232,6 +254,18 @@ 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`,
 `get_broker_instrument_constraints`, and `preview_order_translation`.
+
+Generated Codex config declares the TradingCodex home directory, normally
+`~/.tradingcodex`, in `sandbox_workspace_write.writable_roots`. This bounded
+writable root is required for the central local DB, migration lock, service
+status, and update preference files when the active Codex surface honors
+project-scoped sandbox roots. It is narrower than disabling the sandbox, and
+generated permission rules continue to deny `.env`, secret, and
+broker-credential-shaped paths under both the workspace and TradingCodex home.
+If a Codex CLI or app run still reports `~/.tradingcodex` outside writable
+roots, the user should add it through user-level Codex config or CLI `--add-dir`
+before running service recovery or update-adjacent commands.
+
 Broker/data MCP servers, when explicitly needed for reviewed read-only
 discovery, are registered inside TradingCodex External MCP Gate with
 `./tcx mcp external ...`, not directly in `.codex/config.toml` or
@@ -258,36 +292,58 @@ The autostart path must be:
 - silent on MCP stdout except for MCP protocol messages
 - not required for direct `./tcx mcp stdio` smoke checks
 
-Generated workspaces also support startup health for Codex sessions. Bootstrap
-writes an initial compact diagnostic cache at
+Generated workspaces also support startup context for Codex sessions.
+Bootstrap writes an initial compact diagnostic cache at
 `.tradingcodex/mainagent/server-status.json`, and the `SessionStart` hook
-refreshes it; neither path starts services, updates workspaces, or opens
-browsers. `head-manager` then uses
-`$use-tradingcodex-server` to run service/MCP doctor checks, call
-`./tcx service status` to explain current reachability/version/DB posture, call
-`./tcx service ensure` when recovery is possible, and tell the user that the
-local dashboard is available at `http://127.0.0.1:48267/`. It opens the
-dashboard in a browser only when the user explicitly asks, and it should provide
-the URL only if browser control is unavailable rather than inferring a browser
-security-policy reason. If project MCP config was created or changed, the user
+refreshes it; neither path starts services, updates workspaces, opens browsers,
+or performs package refresh on its own. The emitted context uses marker
+`tradingcodex-session-context` and keeps only compact fields for
+`mode_status`, `permission_status`, `update_status`, `server_status`,
+`allowed_next_actions`, and `routing_status`.
+
+`head-manager` uses `$tcx-server` for service/MCP doctor checks,
+`./tcx service status`, and `./tcx service ensure`. It tells the user that the
+local dashboard is available at `http://127.0.0.1:48267/` and opens it only
+when explicitly asked. If project MCP config was created or changed, the user
 must fully quit and restart Codex and start a new thread because Codex may not
 hot reload project MCP config.
 
-Startup health may also compare the generated workspace version in
-`.tradingcodex/generated/module-lock.json` with the currently installed/running
-`tcx` package version. The workspace version is the local baseline: if it
-differs from the installed `tcx` version, `head-manager` may recommend aligning
-the workspace to the installed version. If the installed `tcx` is known to be
-older than the latest TradingCodex release, workspace update is blocked until
-the package is updated first, so an old package does not refresh the workspace
-with stale templates. 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
+Startup context preserves incompatible service detail from `./tcx service
+status`, including `service_issue`, service/package versions, DB paths, and the
+recorded next action. If the issue is `version_mismatch`, `db_mismatch`, or
+`port_occupied`, `head-manager` must mention the startup notice in its first
+user-facing response and avoid presenting the dashboard as ready until the
+recovery path is handled.
+
+Startup health may compare the generated workspace version in
+`.tradingcodex/generated/module-lock.json` with the installed/running `tcx`
+package version and the latest known TradingCodex release. If update is needed
+while Codex is running under restricted TradingCodex permissions, `head-manager`
+must explain the two supported paths: switch Codex to full access and enable
+TradingCodex build mode, or run the recommended `update_status.command` from a
+terminal. Self-update is allowed only when Codex full access and explicit
+workspace build mode are both active and the user asks for the update. After
+self-update, `head-manager` stops and tells the user to restart Codex.
+
+Build mode is per workspace and explicit:
+
+- `./tcx mode status`
+- `./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
+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
 `suppress_update_recommendation=true`; future new conversations should not
 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.
+
 ## Hooks
 
 Generated hooks are Python scripts. Hook behavior is guidance, not final
@@ -308,14 +364,17 @@ 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"
+  route to the `connector_build` lane and `$tcx-build`, not investment
+  dispatch
 - secret-only routing: credential, token, password, broker-key, or `.env`
   storage/read/rotation prompts create warning context without activating
   investment subagent dispatch unless a separate investment or execution
   request remains
-- startup server diagnostics: `SessionStart` records compact service and MCP
-  config status for `head-manager` to repair through `$use-tradingcodex-server`
-- update recommendation diagnostics: `SessionStart` records generated workspace
-  version drift and respects the TradingCodex home update preference file
+- startup diagnostics: `SessionStart` records compact mode, permission,
+  update, service, and routing status for `head-manager`
+- update recommendation diagnostics: `SessionStart` records package/workspace
+  drift and respects the TradingCodex home update preference file
 
 Hooks load only in trusted projects and may be disabled when
 `features.hooks=false`.

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

@@ -358,12 +358,24 @@ Top-level commands:
 Generated workspace wrapper commands:
 
 - `./tcx doctor`
-- `./tcx update [--no-doctor]`
+- `./tcx update [--no-doctor] [--skip-refresh]`
+- `./tcx update status [--json]`
+- `./tcx mode status`
+- `./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 validate <broker-id>`
 - `./tcx workspace status|list`
 - `./tcx profile status|list|create|select|update`
 - `./tcx subagents status`
 - `./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.
 - `./tcx strategies list|inspect|create|update|activate|archive|delete`
 - `./tcx validate order <path>`
 - `./tcx approve <path>`
@@ -373,9 +385,9 @@ Generated workspace wrapper commands:
 - `./tcx research create|append|get|list|search|export`
 
 Default main-agent skill listing is user-facing, not exhaustive. It shows only
-direct user entrypoints: `orchestrate-workflow`,
-`use-tradingcodex-server`, `strategy-creator`, `postmortem`, and active
-`strategy-*` skills. Full inspection is available through
+direct user entrypoints: `tcx-workflow`, `tcx-server`, `tcx-build`,
+`strategy-creator`, `postmortem`, and active `strategy-*` skills. Full
+inspection is available through
 `./tcx skills list --all` and role-specific `./tcx subagents skills <role>`.
 
 Optional-skill and strategy CRUD CLI commands call the same shared application

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

@@ -93,13 +93,15 @@ dispatch gate.
 
 Natural-language investment requests are sufficient workflow activation for
 fixed-role dispatch. Explicit subagent, parallel, delegated-agent, and
-`$orchestrate-workflow` requests remain supported as manual-control entrypoints,
-but they are not required before `head-manager` routes the work.
+`$tcx-workflow` requests remain supported as manual-control entrypoints, but
+they are not required before `head-manager` routes the work.
 
 | Trigger | Handling |
 | --- | --- |
 | 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 `$orchestrate-workflow` request | The representative workflow skill becomes the primary manual-control orchestrator and dispatches selected subagents. |
+| 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. |
+| 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. |
 | Non-investment repository, docs, or harness administration request | No investment dispatch is required; `head-manager` follows normal Codex coding-agent behavior while preserving execution and secret guardrails. |
@@ -144,7 +146,8 @@ boundary, approval requirements, or information barriers.
 | Situation | Allowed response | Forbidden response |
 | --- | --- | --- |
 | 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 "$orchestrate-workflow analyze Apple" | Spawn selected team or reuse active/completed roles, wait for outputs, then synthesize | Analyze without dispatch |
+| 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 |
 | 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 |
@@ -161,7 +164,7 @@ Instruction/skill separation:
 | Surface | Owns | Must not own |
 | --- | --- | --- |
 | `head-manager` base instructions | durable identity, safety invariants, dispatch fail-closed rule, role boundaries, approved action boundary, skill routing | workflow templates, scenario tables, long checklists, subagent message bodies |
-| Head-manager skills | repeatable workflow procedures, universe maps, scenario gates, subagent briefing/reuse mechanics, synthesis, strategy creation, postmortem workflow | role identity, durable routing authority, MCP allowlists, weakening base guardrails, bypassing role-owned skills, approving or executing directly |
+| Head-manager skills | compact repeatable procedures for workflow routing, server/runtime recovery, build-mode work, strategy creation, and postmortems | role identity, durable routing authority, MCP allowlists, weakening base guardrails, bypassing role-owned skills, approving or executing directly |
 | Fixed subagent TOML | standing role identity, role purpose, artifact wall, model/tool config, MCP allowlist, single-item display nickname candidates, and always-on prohibitions | per-request user intent, workflow lane decisions, source selection, or temporary task-specific context |
 | Role-owned skills | capability procedure, artifact expectations, quality checks, and local output rules | role eligibility, work for other roles, self-approval, execution outside MCP |
 | Main-to-subagent briefs | request-specific assignment envelope: verbatim user request, explicit constraints, workflow consent posture, research artifact language, lane, artifact path, `context_summary`, data-cutoff needs, request-specific out-of-scope items, and return contract | standing role manuals, model/tool config, MCP allowlists, long method checklists, long source-class lists, full artifacts, or repeated guardrail prose |
@@ -192,17 +195,17 @@ role work directly.
 User-visible skill lists are not the same as enabled or installed skills. The
 main-agent user surface should show only direct user entrypoints by default:
 
-- `orchestrate-workflow`
-- `use-tradingcodex-server`
+- `tcx-workflow`
+- `tcx-server`
+- `tcx-build`
 - `strategy-creator`
 - `postmortem`
 
-Internal head-manager harness skills such as `investment-workflow-map`,
-`scenario-quality-gates`, `manage-subagents`, `manage-optional-skills`, and
-`synthesize-decision` remain enabled for `head-manager`; they are hidden from
-the default user-facing list and must not allow implicit invocation from user
-prompts. Compatibility skills such as `tradingcodex-operator` may remain
-installed for explicit older `$skill` prompts, but should not be part of the
+The root context does not load long workflow maps, scenario-quality gates,
+or connector runbooks as always-visible prompt bulk. Those concerns move into
+service-generated compact context, projected role indexes, and the short
+`tcx-*` skills above. Compatibility skills may remain hidden for one release
+cycle for older generated workspaces, but they should not be part of the
 default user-facing or implicit skill surface.
 
 ## Additional Agent Instructions
@@ -224,16 +227,11 @@ Head-manager skill responsibilities:
 
 | Skill | Responsibility |
 | --- | --- |
-| `orchestrate-workflow` | stage sequencing, lane escalation, and movement across research, thesis, portfolio, risk, order, approval, execution, and postmortem |
-| `investment-workflow-map` | universe/workflow classification, source/as-of posture, support gaps, hero/support artifacts, and readiness labels |
-| `scenario-quality-gates` | scenario selection, minimum useful role-team shape, artifact expectations, blocked actions, and quality gates |
-| `use-tradingcodex-server` | Startup health, local dashboard URL guidance, explicit user-requested dashboard opening, Codex restart guidance, TradingCodex MCP setup, native broker connector template registration, capability-profile inspection, order-translation previews, read-only sync, and troubleshooting without granting execution authority |
-| `tradingcodex-operator` | Compatibility entrypoint for one release cycle; redirects users to `$use-tradingcodex-server` and must not add separate broker, approval, or execution authority |
+| `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 |
 | `external-data-source-gate` | read-only external evidence-source constraints and External MCP Gate honesty |
-| `manage-subagents` | fixed-role dispatch mechanics, runtime state/reuse checks, compact briefs, artifact review, and conflict handling |
-| `manage-optional-skills` | file-native optional skill create/update/archive guidance for fixed subagents; use `$skill-creator` for skill authoring while preserving core skills, MCP allowlists, permission profiles, and role identity |
 | `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 |
-| `synthesize-decision` | user-facing decision state after required artifacts or outputs exist |
 | `postmortem` | audit-backed process review and improvement proposals after failures, thesis changes, rejected orders, or executions |
 
 ## Strategy Skills
@@ -286,9 +284,9 @@ deleted, overwritten, or reassigned by user customization. User customization
 starts with optional, role-local skills for fixed subagents.
 
 Optional skill CRUD is managed by the shared application service used by the
-`head-manager`, Django web, Django Ninja, and CLI. `manage-optional-skills`
-should route generic `SKILL.md` authoring through `$skill-creator`, then use
-the shared service path for validation, status, and TOML projection.
+`head-manager`, Django web, Django Ninja, and CLI. Generic `SKILL.md`
+authoring should still follow `$skill-creator` discipline, then use the shared
+service path for validation, status, and TOML projection.
 Optional skill `name` and `description` are read from `SKILL.md` frontmatter;
 the sidecar `agents/tradingcodex.json` stores lifecycle metadata such as role,
 scope, status, and timestamps only.
@@ -354,7 +352,7 @@ and service-layer policy.
 ## Hooks Are Guidance
 
 - `UserPromptSubmit` handles prompt classification, secret warnings, direct-answer prevention context, and duplicate marker management.
-- `SessionStart` writes compact TradingCodex server/MCP diagnostics for `head-manager`; startup recovery and dashboard URL guidance stay in `$use-tradingcodex-server`, while browser opening happens only after an explicit user request.
+- `SessionStart` writes compact TradingCodex mode, permission, update, server/MCP, and routing diagnostics for `head-manager`; incompatible service details such as version mismatch, DB mismatch, and occupied ports must survive into compact context so `head-manager` can mention the startup notice before claiming dashboard readiness. Startup recovery and dashboard URL guidance stay in `$tcx-server`, while self-update and connector implementation stay in `$tcx-build`.
 - Official `UserPromptSubmit` matchers are ignored, so classification happens inside the hook script.
 - Hooks use command type only and do not rely on ordering or concurrency between hooks.
 - Project-local hooks load only in trusted projects and may be disabled when `features.hooks=false`.

{tradingcodex-0.2.3 → tradingcodex-0.2.5}/docs/validation-and-test-plan.md

@@ -223,7 +223,9 @@ logs/results rather than relying only on static checks.
 Scenarios should include:
 
 - broad investment request asks for workflow confirmation or starter prompt
-- explicit `$orchestrate-workflow` routes to selected role team
+- explicit `$tcx-workflow` routes to the selected role team
+- connector build prompts such as "binance 붙여줘" route to `connector_build`
+  and do not dispatch investment subagents
 - negated execution wording such as "no order" stays out of execution routing
 - guardrail-verification wording does not trigger execution
 - secret-only credential, token, broker-key, password, or `.env` prompts create

{tradingcodex-0.2.3 → tradingcodex-0.2.5}/installation.md

@@ -82,6 +82,23 @@ uvx --refresh --from tradingcodex tcx update .
 refreshes generated indexes, applies central DB migrations, records workspace
 provenance, and runs `./tcx doctor` unless `--no-doctor` is passed.
 
+Inside a generated Codex workspace, restricted Codex permissions should not run
+workspace updates because update rewrites protected `.codex`
+prompt/config/hook surfaces. If TradingCodex is already installed and startup
+health says the workspace can be aligned to that installed version,
+`head-manager` will ask you either to switch Codex to full access and enable
+TradingCodex build mode, or run this workspace-only update from your terminal:
+
+```bash
+./tcx update --skip-refresh
+```
+
+If `update_status.can_self_update=true` and you explicitly ask for the update,
+`head-manager` can run it directly, then it will stop and tell you to fully
+restart Codex. If a package update is required first, run the
+`uvx --refresh ... tcx update .` or installer-script update command from your
+terminal, then fully restart Codex.
+
 After update, runtime order flows use central DB `OrderTicket` records directly.
 
 After update, fully quit and restart Codex, then start from a new thread in the

{tradingcodex-0.2.3 → tradingcodex-0.2.5}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "tradingcodex"
-version = "0.2.3"
+version = "0.2.5"
 description = "Codex-native trading harness with a Django service plane and approved action boundary."
 readme = "README.md"
 requires-python = ">=3.11,<3.15"
@@ -50,6 +50,7 @@ include-package-data = true
 include = ["tradingcodex_cli*", "tradingcodex_service*", "apps*", "workspace_templates*"]
 
 [tool.setuptools.package-data]
+tradingcodex_service = ["templates/**/*", "static/**/*"]
 workspace_templates = ["**/*", "**/.*", "**/.*/**/*"]
 
 [tool.setuptools.exclude-package-data]

{tradingcodex-0.2.3 → tradingcodex-0.2.5}/tests/test_e2e_user_scenarios.py

@@ -81,9 +81,9 @@ def test_generated_workspace_codex_cli_user_scenario_matrix(tmp_path: Path) -> N
             False,
         ),
         (
-            "$orchestrate-workflow NVDA earnings preview and catalyst review, no order and no trading",
+            "$tcx-workflow NVDA earnings preview and catalyst review, no order and no trading",
             "thesis_review",
-            ["fundamental-analyst", "technical-analyst", "news-analyst", "macro-analyst", "valuation-analyst"],
+            ["fundamental-analyst", "technical-analyst", "news-analyst", "valuation-analyst"],
             False,
         ),
         (
@@ -128,6 +128,12 @@ def test_generated_workspace_codex_cli_user_scenario_matrix(tmp_path: Path) -> N
             [],
             True,
         ),
+        (
+            "binance 붙여줘. no order, no execution, do not read secrets.",
+            "connector_build",
+            [],
+            False,
+        ),
     ]
     for index, (prompt, lane, roles, secret_warning) in enumerate(prompt_cases):
         gate = hook_context(workspace, prompt, env_extra, via_hooks_json=index == 0)
@@ -136,10 +142,10 @@ def test_generated_workspace_codex_cli_user_scenario_matrix(tmp_path: Path) -> N
         assert gate["required_subagents"] == roles
         assert gate["secret_warning"] is secret_warning
         assert gate["confirmation_required"] is False
-        assert gate["context_mode"] == "compact_workflow_gate_v1"
+        assert gate["context_mode"] == "compact_workflow_gate"
         assert gate["starter_prompt_path"] == ".tradingcodex/mainagent/latest-user-prompt-gate.json"
         assert "starter_prompt" not in gate
-        assert len(json.dumps(gate, ensure_ascii=False)) < 1600
+        assert len(json.dumps(gate, ensure_ascii=False)) < 1800
         if roles:
             persisted_gate = json.loads((workspace / ".tradingcodex" / "mainagent" / "latest-user-prompt-gate.json").read_text(encoding="utf-8"))
             starter = persisted_gate["starter_prompt"]
@@ -165,7 +171,7 @@ def test_generated_workspace_codex_cli_user_scenario_matrix(tmp_path: Path) -> N
     status = json.loads(tcx(workspace, env_extra, "subagents", "status").stdout)
     assert status["installed_count"] == 9
     assert status["fixed_roster_ok"] is True
-    assert status["skills_installed"] == 24
+    assert status["skills_installed"] == 19
     plan = json.loads(tcx(workspace, env_extra, "subagents", "plan", "--all").stdout)
     assert plan["requested_count"] == 9
     assert plan["parallel_spawn_ok"] is True