tradingcodex 1.2.0__tar.gz → 1.2.2__tar.gz

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/CHANGELOG.md

@@ -2,6 +2,38 @@
 
 ## Unreleased
 
+## 1.2.2 - 2026-07-22
+
+- Validate Codex CLI 0.145.0 as the current reference while retaining 0.144.4
+  as the compatibility floor; adopt its stable MultiAgent V2 schema by leaving
+  nesting and concurrency to native Codex while preserving strict config,
+  permission, hook, MCP, and role-model projection checks.
+- Restore the Head Manager's generated `export_dataset_csv` projection by
+  registering its canonical MCP schema, role boundary, and export capability,
+  with a generated-config-to-registry regression check.
+- Stop automated GitHub Release notes at the next changelog heading so a
+  release contains only its matching version section.
+
+## 1.2.1 - 2026-07-21
+
+- Create or refresh the GitHub Release from the exact verified distributions
+  and matching changelog section only after protected PyPI publication succeeds.
+- Run Python and frontend CI gates in parallel, verify releases on Apple Silicon
+  macOS, retain temporary distributions for seven days, remove the duplicate
+  Ubuntu wheel smoke, and reduce upgrade validation to the latest public
+  predecessor-to-candidate path.
+
+- Let users author Investor Context directly with native Codex while retaining
+  lifecycle protection for enable, disable, and clear operations.
+- Judge research evidence by the claim, intended use, and update cadence rather
+  than by an official-versus-available source label; preserve valid partial
+  fields and fetch only the missing decision-relevant coverage.
+- Remove the generic analysis prompt-submit hook from ordinary requests while
+  retaining grant revocation and reserved safety actions.
+- For short-horizon directional questions, resolve the relevant market session
+  and include market-wide or macro expertise when transmission could materially
+  change direction, range, or scenario weights without imposing a fixed roster.
+
 ## 1.2.0 - 2026-07-20
 
 - Refresh the manual GitHub Pages workflow to the current Node 24 action

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: tradingcodex
-Version: 1.2.0
+Version: 1.2.2
 Summary: Local-first investment operating system for Codex-native research and service-gated execution.
 Author: TradingCodex Authors
 License-Expression: Apache-2.0

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/README.md

@@ -84,7 +84,8 @@ into every layer. If two layers disagree, fix the owning `docs/` page first.
 
 - [Validation And Test Plan](validation-and-test-plan.md) — complete validation
   matrix; use the smallest relevant subset during iteration.
-- [Release Readiness](release-readiness.md) — release-specific evidence.
+- [Release Readiness](release-readiness.md) — reusable release and publication
+  checklist; live status remains in GitHub and PyPI.
 - [Deployment](deployment.md) — packaging, publication, update, and CI policy.
 - [Licensing And Commercialization](licensing-and-commercialization.md) — open
   source, generated workspace, trademark, and legal-review boundaries.

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/codex-native-orchestration.md

@@ -81,7 +81,8 @@ conflicts with Strategy.
 
 ## Delegation Contract
 
-MultiAgent V2 exposes the generated role profiles with a depth-one boundary.
+MultiAgent V2 exposes the generated role profiles through native Codex
+delegation.
 Head Manager prefers an exact profile when its specialty is useful and passes a
 compact role-owned brief rather than the full root history. Role TOML supplies
 the direct fixed model settings; their values and fallback eligibility are owned
@@ -98,11 +99,15 @@ Use `followup_task` when a live child still owns a correction or clarification.
 Start another child for a new specialty, an unavailable session, or independent
 review. Apply the canonical fallback boundary in
 [Roles, Skills, And Workflows](roles-skills-and-workflows.md). A child cannot
-approve, execute, access a broker, or emulate Head Manager. Children never
-delegate recursively. Head Manager waits only while a live child has useful work
-and reports lifecycle events only from native tool and child-lifecycle results
-in the current run. Native wait is wait-any and may serialize with no explicit
-target list; that representation is not failure by itself.
+approve, execute, access a broker, or emulate Head Manager. Whether to delegate
+a distinct child-owned subtask further is a native Codex decision, not a
+TradingCodex workflow requirement. Every descendant remains subject to its
+selected projected role and the shared evidence, authority, and safety
+boundaries. Head Manager
+waits only while a live child has useful work and reports lifecycle events only
+from native tool and child-lifecycle results in the current run. Native wait is
+wait-any and may serialize with no explicit target list; that representation is
+not failure by itself.
 
 When a Brain applies, the assignment contains the question Head Manager derived
 from it, not the Brain body or a delegation of Brain authority. Brain content is

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/data-sources-and-openbb.md

@@ -31,6 +31,23 @@ they are not the user capability in step 2. For structured prices, OHLCV,
 fundamentals, estimates, or macro series, an available direct OpenBB route is
 attempted before that fallback unless the user selected another provider.
 
+Evidence is fit to a claim and intended use rather than accepted or rejected by
+provider class. Original public records remain preferred when a claim requires
+source-of-record authority, but attributable non-primary evidence may support
+the fields and periods it actually covers. Missing or ambiguous coverage limits
+only dependent claims and actions; it does not erase independent valid fields
+or prevent factual and screen-grade research. This preserves the distinction
+between evidence usability and decision or execution readiness without adding
+a provider trust score, allowlist, or routing registry.
+
+Freshness is relative to the requested as-of, the source's observation or
+publication cadence, the relevant instrument or venue session, and the claim.
+The latest completed period may be the current usable anchor before another
+period exists. Offset-free provider timestamps remain explicitly ambiguous and
+epoch values are converted once; neither is repaired by inventing a timezone.
+A material missing slice that remains obtainable is fetched from the next
+relevant source or returned to its live owner before an evidence-gap abstention.
+
 The procedure adds point-in-time context only when structured or historical
 evidence matters to a conclusion. It preserves issuer identity and
 instrument/venue, unit/currency/timezone, raw-versus-adjusted price policy,

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/deployment.md

@@ -109,9 +109,9 @@ files are never replaced.
 ## Maintainer Prerequisites
 
 Release verification uses Python 3.11 and Node 22 for the complete source and
-frontend gates. After that single quality job builds the candidate
-distribution, the calculation-runtime matrix reuses the exact wheel on x86-64
-Linux, Intel macOS, and native Windows under Python 3.11, 3.12, 3.13, and 3.14.
+frontend gates. The release workflow then builds the candidate once, and the
+calculation-runtime matrix reuses that exact wheel on x86-64 Linux, Apple
+Silicon macOS, and native Windows under Python 3.11, 3.12, 3.13, and 3.14.
 Each matrix job provisions the hash-locked runtime and exercises attach,
 doctor, direct package imports, exploratory compatibility, prepared recording,
 and exact reuse. Node remains a maintainer-only build dependency and is not
@@ -156,7 +156,7 @@ find . -maxdepth 1 -name '*.egg-info' -type d -exec rm -rf {} +
 python3.11 -m build
 python3.11 -m twine check dist/*
 python3.11 tests/platform_wheel_smoke.py --wheel-dir dist
-python3.11 tests/release_upgrade_smoke.py --wheel-dir dist --from-version 1.0.2
+python3.11 tests/release_upgrade_smoke.py --wheel-dir dist
 ```
 
 The wheel smoke installs only the built wheel into a clean virtual environment,
@@ -166,13 +166,13 @@ stdio, exercises the local service, and loads the packaged SPA and assets.
 It also provisions the content-addressed calculation runtime, verifies its
 manifest/lock/launcher hashes and exact imports, and exercises prepared and
 exploratory `tcx-calc` modes without importing Django from the runner.
-The release-upgrade smoke starts from the published `1.0.2` package, updates
-that attached workspace with the built candidate wheel, and verifies preserved
-workspace and runtime identity, user-owned state, and explicit home, DB, and
-service-address settings alongside the refreshed generated contract. It also
-preserves the exact provider approval identity and timestamp, compares every
-byte in the immutable provider snapshot, and proves that the candidate runtime
-loads that approved snapshot after the update.
+The release-upgrade smoke reads the candidate version from the built wheel,
+selects the latest preceding stable release published on PyPI, and verifies
+that single predecessor-to-candidate path. It preserves workspace and runtime
+identity, user-owned state, explicit home, DB, service-address settings, and
+provider approval evidence alongside the refreshed generated contract. Older
+release pairs are not replayed unless a separate migration contract explicitly
+requires them.
 
 Harness, role, prompt, skill, hook, policy, MCP, or generated-template changes
 also require the disposable-workspace and Codex-native checks documented in
@@ -180,8 +180,8 @@ also require the disposable-workspace and Codex-native checks documented in
 
 ## CI And Release Automation
 
-`.github/workflows/ci.yml` is test-only. One Ubuntu/Python 3.11 job runs the
-frontend determinism check, complete Python suite, and framework gates. It does
+`.github/workflows/ci.yml` is test-only. Parallel Ubuntu jobs run the frontend
+determinism check and the Python 3.11 source/framework gates. It does
 not construct or upload a wheel or source distribution, run release-upgrade or
 native-runtime matrices, or publish anything. Documentation-, guide-, OpenWiki-,
 and asset-only pushes or pull requests skip this workflow. Source-bearing pull
@@ -198,16 +198,18 @@ requests and pushes still receive the normal source-quality checks.
 - the tagged commit is on `origin/main`
 - the wheel and source-distribution filenames carry the same version
 - `dist/` contains exactly that one wheel and one source distribution
-- the built wheel passes the Ubuntu wheel and prior-release update smokes
+- the built wheel passes the prior-release update smoke and the platform matrix
 - the protected `pypi` environment approves Trusted Publishing
 
 The release workflow has one build/verification job followed by the required
-Python 3.11-3.14 Linux, Intel-macOS, and native-Windows calculation-runtime
+Python 3.11-3.14 Linux, Apple-Silicon-macOS, and native-Windows calculation-runtime
 matrix. When publication is requested, one protected PyPI job downloads that
-exact artifact and uploads it; no job rebuilds the distribution after
-verification. These distribution and platform jobs run only after an explicit
-`Manual Release` dispatch, never because a branch, tag, development commit, or
-documentation change was pushed.
+exact artifact and uploads it. After PyPI succeeds, a GitHub Release job
+downloads the same artifact, uses the matching `CHANGELOG.md` section as its
+notes, and creates or refreshes the tag's wheel and source-distribution assets.
+No job rebuilds the distribution after verification. These distribution and
+platform jobs run only after an explicit `Manual Release` dispatch, never
+because a branch, tag, development commit, or documentation change was pushed.
 
 ## User Guide Pages
 
@@ -246,7 +248,8 @@ The guide for this repository is published at
 5. In GitHub Actions, run `Manual Release` from that tag with the exact
    `release_version`. Use `publish_pypi=true` for an approved publication; use
    the optional `publish_pypi=false` rehearsal when release risk warrants an
-   additional hosted build.
+   additional hosted build. A successful approved publication also creates or
+   refreshes the matching GitHub Release from the verified artifacts.
 
 Pushing a branch or tag does not publish by itself.
 
@@ -283,7 +286,7 @@ sh "$SOURCE_ROOT/install.sh" \
 On native Windows PowerShell:
 
 ```powershell
-$ReleaseVersion = "1.2.0"
+$ReleaseVersion = "<released-version>"
 $Workspace = Join-Path $env:TEMP "tcx-pypi-$ReleaseVersion"
 New-Item -ItemType Directory -Force $Workspace | Out-Null
 Set-Location $Workspace

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/generated-workspaces.md

@@ -130,10 +130,10 @@ paths, reserved namespaces, and managed block markers define the boundary:
 | Class | Representative paths | Update contract |
 | --- | --- | --- |
 | Release-managed generated files | `AGENTS.md`, `pyproject.toml`, `tcx`, `tcx.cmd`, `.codex/config.toml`, `.codex/agents/*.toml`, `.codex/hooks/*`, `.agents/skills/tcx-*`, bundled `.tradingcodex/subagents/skills/**/tcx-*`, schemas, policies, launchers, generated indexes, and protocol-owned workspace identity/status files | Template and projection files are listed and hashed in the module lock. The lock cannot inventory itself; the immutable workspace manifest and rebuildable bootstrap/status files are separately protocol-owned. Update re-renders or re-projects these files from the current package and canonical state. Direct edits are unsupported and may be replaced. |
-| User-selected managed overlays | `.tradingcodex/agent-instructions/*.md`, `.tradingcodex/user/*`, `.agents/skills/strategy-*`, optional role skills, `investment-brains/*` authoring sources, `wiki-packages/*` shareable Wiki sources, `wikis/local`, and installed Brain/Wiki registries, packages, and projections | The owning lifecycle service validates managed state. Update preserves canonical state, user-owned Wiki/Brain sources, local Wiki pages, installed packages, registries, and active projections. |
+| User-selected managed overlays | `.tradingcodex/agent-instructions/*.md`, `.agents/skills/strategy-*`, optional role skills, `investment-brains/*` authoring sources, `wiki-packages/*` shareable Wiki sources, `wikis/local`, and installed Brain/Wiki registries, packages, and projections | The owning lifecycle service validates managed state. Update preserves canonical state, user-owned Wiki/Brain sources, local Wiki pages, installed packages, registries, and active projections. |
 | Workflow and research artifacts | `trading/research/`, `trading/reports/`, `trading/forecasts/`, `trading/decisions/`, `trading/evaluations/`, postmortems, lesson state, and per-run provenance | These are workspace state, not release payload. Update preserves them; template-owned `.gitkeep` files in the same directories do not transfer ownership of sibling artifacts. |
 | Local/private runtime state | The external `TRADINGCODEX_HOME`, central DB, ignored session/status/cache/audit files, secrets, credentials, and private Investor Context | These remain outside versionable product state or inside the managed privacy-ignore block. Rebuildable status/cache files may be refreshed; durable authority never moves into the workspace. |
-| Ordinary user files | Any non-reserved path not listed in the generated-file inventory | Update leaves them untouched. A file placed in a reserved managed namespace may be rejected as a collision rather than adopted or deleted. |
+| Ordinary user files | `.tradingcodex/user/*` and any non-reserved path not listed in the generated-file inventory | Native workspace tools may update these files within the active permission profile. Update leaves them untouched. A file placed in another reserved managed namespace may be rejected as a collision rather than adopted or deleted. |
 
 In particular, `.tradingcodex/config.yaml` is a generated control input despite
 its name; use the documented customization and lifecycle surfaces instead of
@@ -289,9 +289,9 @@ Generated workspaces contain:
 - no default ticker team: a broad company prompt does not expand to a fixed
   analyst roster. Head Manager derives current questions, dispatches only roles
   justified by them, and reassesses from authenticated evidence
-- compact hook context contains session health or an analysis-start hint only;
-  Head Manager owns run creation, decision-quality, forecast, Investor Context,
-  and method choices
+- compact hook context contains session health or explicit current-turn
+  authority context only; Head Manager owns run creation, decision-quality,
+  forecast, Investor Context, and method choices
 - native role-profile delegation: generated config exposes the nine specialist
   profiles through MultiAgent V2. Head Manager prefers the exact profile, uses
   `followup_task` for owner corrections, and follows the canonical role and
@@ -534,7 +534,7 @@ That explicit overlay rule applies to external skill procedures, not to
 read-only app, connector, MCP, or data tools used as evidence. A role whose
 assignment needs external data or preserves a user-named provider first checks
 the current task's callable tool surface and uses the runtime's available
-deferred-tool discovery surface when needed. The Codex 0.144.4 reference
+deferred-tool discovery surface when needed. The Codex 0.145.0 reference
 contract first resolves at most 12 names with
 `text(ALL_TOOLS.filter(x => x.name.includes("<provider-or-keyword>")).slice(0, 12).map(x => x.name))`.
 One supported query may combine one to four literal `name.includes`
@@ -586,14 +586,22 @@ runs, hard-failure checks, blind review, and resolved outcomes.
 Generated `.codex/config.toml` enables MultiAgent V2 with visible spawn
 metadata and the `agents` tool namespace. It keeps every
 `.codex/agents/*.toml` role discoverable while setting
-`features.multi_agent_v2.enabled = true` and `agents.max_depth = 1`. The
-V1-only `agents.max_threads` key is absent because Codex rejects it when V2 is
-enabled. Codex owns concurrency and scheduling. Head Manager chooses useful
-profiles and follows up with an owner when appropriate. Role eligibility and
-fallback are defined in [Roles, Skills, And Workflows](roles-skills-and-workflows.md).
-Children cannot recursively dispatch. Root model and reasoning settings are
-inherited, and direct fixed-role TOML model settings are projected, but `doctor`
-does not duplicate native model availability or lifecycle checks.
+`features.multi_agent_v2.enabled = true`. TradingCodex does not set
+`agents.max_depth`, `agents.max_threads`, or
+`agents.max_concurrent_threads_per_session`; Codex 0.145.0 ignores
+`agents.max_depth` for V2, retains `agents.max_threads` as a compatibility
+alias, and owns nesting, concurrency, and scheduling. Head Manager chooses
+useful profiles and follows up with an owner when appropriate. Role eligibility
+and fallback are defined in [Roles, Skills, And Workflows](roles-skills-and-workflows.md).
+Whether to delegate distinct child-owned work further is a native Codex
+decision, not a TradingCodex workflow requirement. Every descendant remains
+subject to its selected projected role and TradingCodex safety and service
+gates. Root model and reasoning settings are inherited, and direct fixed-role
+TOML model settings are projected, but `doctor` does not duplicate native model
+availability or lifecycle checks. Codex 0.145.0 exposes optional per-spawn model
+and reasoning overrides by default; TradingCodex neither disables nor requires
+them. A spawn without an explicit override follows native inheritance and role
+config resolution.
 
 Workspace template modules are deployment projections. Agent and skill
 ownership comes from the Python agent registry and is projected
@@ -823,7 +831,10 @@ Inside a generated workspace, normal `head-manager` and fixed-role analysis
 threads inherit the `trading-research` permission profile. They can use normal
 shell, data tools, and credential-free public HTTP, read ordinary
 workspace inputs, and write user-owned files outside `trading/`; disposable
-intermediates belong under `$TRADINGCODEX_SCRATCH`. Fixed-role Python
+intermediates belong under `$TRADINGCODEX_SCRATCH`. The exact
+`.tradingcodex/user/` subtree is also user-owned and writable so confirmed
+Investor Context can be managed with native file tools; the rest of
+`.tradingcodex/` remains protected. Fixed-role Python
 calculations use only the generated scratch-local `tcx-calc` contract. They
 cannot modify
 `trading/`, generated control files, or the TradingCodex home, DB, attached
@@ -865,10 +876,11 @@ Generated root config sets `default_permissions = "trading-research"` and
 defines two custom profiles. It deliberately omits legacy `sandbox_mode` from
 the root and every fixed-role TOML because any loaded `sandbox_mode` overrides
 custom permission profiles in Codex. This contract requires Codex CLI 0.144.4
-or later on a locally supported platform. Version 0.144.4 is the current
+or later on a locally supported platform. Version 0.145.0 is the current
 release-validation reference for permission profiles, hooks, required MCP,
-deferred MCP calls, and the explicit V2 feature table. Older versions fail the
-Codex runtime doctor check. These remain version-sensitive
+deferred MCP calls, and the explicit V2 feature table. Versions below the
+compatibility floor fail the Codex runtime doctor check; compatible non-reference
+versions warn. These remain version-sensitive
 surfaces, so release validation includes strict config/feature inspection and
 a real native smoke.
 See the [Codex permissions reference](https://learn.chatgpt.com/docs/permissions).
@@ -1357,10 +1369,10 @@ because hook policy is an agent-runtime boundary.
   detector participates
 - compact `SessionStart` health context with service status, viewer location,
   and restart posture only
-- compact `UserPromptSubmit` analysis-start hint: Head Manager interprets the
-  request directly, keeps narrow answers direct, calls `begin_analysis_run`
-  only for a new workflow that needs durable provenance, and reuses the current
-  task's run ID when continuing that workflow
+- ordinary `UserPromptSubmit` turns emit no analysis context. Head Manager
+  interprets the request directly, keeps narrow answers direct, calls
+  `begin_analysis_run` only for a new workflow that needs durable provenance,
+  and reuses the current task's run ID when continuing that workflow
 - audit records TradingCodex safety gates, grants, immediate execution, and
   service failures. `PreToolUse` also records a sanitized external-tool
   observation containing only the exact tool FQN, a secret-free canonical
@@ -1579,7 +1591,7 @@ Codex-native bootstrap verification:
   workspace. The canonical workspace must
   either be interactively trusted or receive the one-run `projects={...}` trust
   override shown in `AGENTS.md`. A full fixed-role lifecycle smoke must use
-  persisted trust for all five generated project hooks. Codex 0.144.4 does not
+  persisted trust for all five generated project hooks. Codex 0.145.0 does not
   carry the one-run `--dangerously-bypass-hook-trust` flag through the role
   config reload used by an exact V2 child, so that flag may be used only for
   root/config diagnostics and is not lifecycle acceptance. It also does not

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/harness.md

@@ -76,7 +76,7 @@ source dumps. This is skill guidance, not a provider router or trust engine.
 
 The generated hook is deliberately small. It owns:
 
-- compact session health and a stateless analysis-start hint;
+- compact session health and explicit current-turn authority context;
 - exact parsing of reserved root action prompts;
 - current-turn proof issue, reservation, and injection for Build, Brain,
   Strategy, and final order service calls;

tradingcodex-1.2.2/docs/release-readiness.md

@@ -0,0 +1,70 @@
+# Release Readiness
+
+This is a reusable release checklist, not a live status page. GitHub Actions,
+GitHub Releases, and PyPI own the current state of a particular release.
+
+## Candidate Contract
+
+- `tradingcodex_service/version.py` is the only package-version source.
+- `CHANGELOG.md` contains a matching dated release section.
+- The release tag is the annotated `v<version>` tag on a commit in `main`.
+- One build produces exactly one wheel and one source distribution. Every
+  later job downloads those files instead of rebuilding them.
+
+## Required Gates
+
+| Area | Evidence required |
+| --- | --- |
+| Source and schema | Full Python suite, Django check, migration dry-run, compileall, and whitespace review pass. |
+| Frontend | Locked tests and build pass; committed static assets are deterministic. |
+| Generated workspace | A disposable development workspace passes doctor, service, launcher, MCP, and affected projection checks. |
+| Native Codex | Prompt, role, skill, hook, or orchestration changes pass the observed acceptance route in the validation plan. |
+| Distribution | Wheel and source distribution pass metadata checks and the clean-wheel smoke. |
+| Platform runtime | The exact wheel passes Python 3.11-3.14 on supported Linux, Apple Silicon macOS, and native Windows runners. |
+| Upgrade | The latest preceding stable PyPI release updates to the candidate while preserving user and service identity. |
+| Publication | Protected PyPI publishing succeeds before the matching GitHub Release is created or refreshed. |
+| Post-publish | A pinned PyPI install passes fresh attach, doctor, metadata, and update checks. |
+
+Use the smallest applicable gates while iterating. Run the complete release
+set only for a candidate that is ready to publish.
+
+## Upgrade Gate
+
+The default and only routine cross-version check is:
+
+```text
+latest preceding public release -> candidate release
+```
+
+`tests/release_upgrade_smoke.py` reads the candidate version from the built
+wheel and selects the greatest stable PyPI version below it. It does not replay
+every historical release pair. A major-version migration or an explicitly
+supported older direct-upgrade path requires its own documented gate.
+
+```bash
+python3.11 tests/release_upgrade_smoke.py --wheel-dir dist
+```
+
+The smoke verifies preserved workspace identity, paper scope, workspace-native
+artifacts, user-owned Brains and Strategies, connector state, runtime home,
+database override, service address, and provider approval evidence.
+
+## Publish
+
+After the candidate gates pass:
+
+1. Merge the release commit to `main` and wait for CI.
+2. Create and push the annotated `v<version>` tag.
+3. In GitHub Actions, dispatch `Manual Release` from that tag with
+   `release_version=$RELEASE_VERSION` and `publish_pypi=true`.
+4. Approve the protected `pypi` environment.
+5. Verify the exact PyPI files and GitHub Release, then run the post-publish
+   checks from [Deployment](deployment.md).
+
+Pushing a branch or tag alone does not publish anything.
+
+## Claim Boundary
+
+Software release readiness does not establish investment performance, return
+improvement, model superiority, or financial safety. Those claims require
+separate evidence and review.

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/roles-skills-and-workflows.md

@@ -14,7 +14,7 @@ orchestration, handoffs, overlays, and execution separation.
 | Fixed-role base prompt | shared child safety, evidence/handoff invariants, compact artifact reads, and gap handling | provider procedure, specialist identity, cross-role scheduling |
 | Fixed-role TOML | concise specialist identity, unique boundary, web posture, tools, and MCP principal | shared evidence procedure, cross-role scheduling, or model policy |
 | Role skills | domain procedure and output quality | role identity or authority |
-| Hooks | compact session health and stateless analysis hints, reserved action parsing, proof injection, and TradingCodex-owned safety-gate audit | natural-language routing, run/session ownership, child lifecycle, role selection, generic shell/network policy, or lane/team/DAG selection |
+| Hooks | compact session health and current-turn authority context, reserved action parsing, proof injection, and TradingCodex-owned safety-gate audit | natural-language routing, run/session ownership, child lifecycle, role selection, generic shell/network policy, or lane/team/DAG selection |
 | Django services/MCP | run provenance, principal/tool checks, artifact lineage, policy/order/approval/broker/execution/audit state; one protected turn-grant consumer plus no raw final mutation | investment research orchestration or model-granted execution authority |
 
 The current Codex authoring contract follows the official
@@ -143,9 +143,14 @@ readiness limits. It does not impose sentence tags or a template on narrow
 answers or intermediate role work.
 
 Broad analysis is not a fixed template. A factual company profile may need one
-fundamental role. A near-term market forecast may begin with macro, technical,
-and news roles. A recommendation or portfolio/risk decision usually needs
-independent judgment. Evidence can change the next role.
+fundamental role. For a horizon-sensitive directional forecast, Head Manager
+first resolves the relevant market session and separates instrument-specific
+from market-wide drivers. At one market session or less, market-wide regime or
+cross-asset transmission is presumed material unless the request isolates an
+idiosyncratic event; `macro-analyst` owns that question when it could change
+direction, range, or scenario weights. This is a causal-coverage rule, not a
+fixed macro/technical/news roster. A recommendation or portfolio/risk decision
+usually needs independent judgment. Evidence can change the next role.
 
 The shared workflow treats inside-out economics, outside-in peers and base
 rates, upstream/downstream value-chain position, time and expectations, and
@@ -221,8 +226,11 @@ Start a fresh child for a new specialty, an unavailable session, or independent
 review. The Dynamic Workflow fallback boundary applies here. A generic child
 retains the same research-only scope, evidence standard, no-secret boundary,
 and no-order boundary; it cannot approve, execute, access a broker, or act as
-Head Manager. Children never delegate recursively. Wait only while a live child
-has useful work. Native
+Head Manager. Whether to delegate a distinct child-owned subtask further is a
+native Codex decision, not a workflow requirement. Each descendant remains
+subject to its selected projected role and the shared evidence, authority, and
+safety boundaries. Wait only while a live child has useful work.
+Native
 wait-any may serialize without explicit targets; verify lifecycle through the
 native tool result and child session events rather than treating that as failure.
 
@@ -255,7 +263,7 @@ same contract error repeats.
 The same bounded rule applies across role MCP use: a documented terminal
 outcome such as stored, updated, existing, reused, or prepared ends that call;
 an unchanged deterministic failure is never blindly resubmitted. Under the
-Codex 0.144.4 deferred-tool contract, unknown-provider resolution starts with
+Codex 0.145.0 deferred-tool contract, unknown-provider resolution starts with
 the canonical names-only query
 `text(ALL_TOOLS.filter(x => x.name.includes("<provider-or-keyword>")).slice(0, 12).map(x => x.name))`.
 One names-only query may combine at most four literal `name.includes`

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/system-architecture.md

@@ -137,7 +137,7 @@ Control-plane maintainability depends on clear ownership:
   and the three native execution protocol bundles;
   `.tradingcodex/subagents/skills/*` owns role procedures and output shape.
   Skill files do not own durable role eligibility or MCP authority.
-- `.codex/hooks/*` owns compact session health and analysis-start hints, exact
+- `.codex/hooks/*` owns compact session health and current-turn authority context, exact
   explicit extension syntax reporting, safety-gate audit, and deterministic interception of
   the three root-native execution skills plus normalized first-meaningful-line
   `$tcx-build`, `$tcx-brain`, `$tcx-wiki`, and `$tcx-strategy` contracts. It does not classify natural language, select roles,

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/user-facing-skills.md

@@ -44,7 +44,7 @@ is not a Head Manager entrypoint.
 | --- | --- | --- |
 | `tcx-plan` | Clarify scope, constraints, action boundaries, and stop conditions before an immediate or recurring task. | Compact user mandate and missing-field or blocked posture; never a server dispatch plan or selected team. |
 | `tcx-automate` | Create or update Codex app Scheduled Tasks for simple research, monitoring, recurring analysis, portfolio/status review, order drafting, assisted execution, optional turn-authorized execution, or explicitly delegated turn-authorized Build work. | Schedule plus a durable runtime prompt that invokes the actual work skill, not `tcx-automate` recursively. |
-| `tcx-investor-context` | Interview and preview workspace suitability context; persistent status/update/enable/disable/clear is handed to an explicit user-terminal command. | User-confirmed proposed values, exact terminal action, default application state, and remaining gaps. |
+| `tcx-investor-context` | Interview and manage workspace suitability context as an ordinary user-owned file. | Confirmed saved values, default application state, and remaining gaps. |
 
 ## Entrypoint Rules
 
@@ -107,11 +107,10 @@ answer ends with one concise `Wiki used:` line containing only the
 workspace-relative paths of pages actually used. Current facts that support an
 investment conclusion still require normal Source Gate verification.
 
-`tcx-investor-context` interviews and previews only the optional
-workspace-local suitability file in the Codex turn. Persistent status, update,
-enable, disable, or clear is performed by the user with the exact interactive
-terminal command returned after confirmation; the skill does not bypass the
-Build shell gate. Its persistent enable/disable state is separate from skill availability,
+`tcx-investor-context` reads, interviews for, previews, and updates the optional
+workspace-local suitability file with native workspace file tools after user
+confirmation. This ordinary user-owned file does not require a Build turn, MCP
+service, or terminal handoff. Its persistent enable/disable state is separate from skill availability,
 strategy rules, and internal paper account scope. It does not run investment
 analysis or grant authority. Native run binding follows the saved workspace default;
 the read-only viewer offers no one-run override and never rewrites the file.

{tradingcodex-1.2.0 → tradingcodex-1.2.2}/docs/validation-and-test-plan.md

@@ -266,8 +266,9 @@ Smoke coverage should verify:
   Manager and role-owned live research for the six evidence producers without
   treating a host finance skill as a dependency
 - generated `.codex/config.toml` explicitly enables MultiAgent V2, reports it
-  enabled through `codex features list`, leaves concurrency to Codex, and omits
-  the incompatible V1 `agents.max_threads` key
+  enabled through `codex features list`, leaves nesting and concurrency to
+  Codex, and omits TradingCodex-owned `agents.max_depth`,
+  `agents.max_threads`, and `agents.max_concurrent_threads_per_session`
 - skill/projection manifests identify the finite managed inventory, declare
   runtime discovery incomplete, and resolve exact root/role skill paths
 - two generated workspaces have different workspace ids
@@ -293,21 +294,22 @@ flags and fixed read-only Codex inventory subprocess handling.
 
 Calculation runtime release coverage must additionally resolve the complete
 hash-locked wheel set for Python 3.11, 3.12, 3.13, and 3.14 on supported
-macOS, Linux, and native Windows x86-64 targets. Every target verifies the
-runtime manifest, launcher hash, exact package imports, one prepared envelope,
-and one exploratory compatibility run. Missing wheels must fail attach before
-workspace mutation; validation must never permit a source build as fallback.
+Apple Silicon macOS, Linux x86-64, and native Windows x86-64 targets. Every
+target verifies the runtime manifest, launcher hash, exact package imports, one
+prepared envelope, and one exploratory compatibility run. Missing wheels must
+fail attach before workspace mutation; validation must never permit a source
+build as fallback.
 
 After building a wheel, run:
 
 ```bash
 python tests/platform_wheel_smoke.py --wheel-dir dist
-python tests/release_upgrade_smoke.py --wheel-dir dist --from-version 1.0.2
+python tests/release_upgrade_smoke.py --wheel-dir dist
 ```
 
 GitHub Actions keeps the complete Python/Django suite on Ubuntu/Python 3.11 and
 then runs that same clean-wheel helper for Python 3.11-3.14 on x86-64 Linux,
-Intel macOS, and native Windows. Release publication depends on the full matrix.
+Apple Silicon macOS, and native Windows. Release publication depends on the full matrix.
 The helper uses
 `tempfile`, a space-containing wheel path and workspace, parses root plus all
 role TOML and generated YAML/JSON, runs `tcx` on POSIX or `tcx.cmd` on Windows,
@@ -645,7 +647,7 @@ Scenarios should include:
 - explicit investor-context updates persist to the workspace Markdown file;
   enable/disable changes the default, native run binding follows that default,
   while the viewer offers no one-run override
-- Codex `UserPromptSubmit` generated hooks keep analysis-start hints under budget
+- Codex `UserPromptSubmit` generated hooks emit no context for ordinary prompts
   and never classify meaning, choose roles, or create a run; `begin_analysis_run` seals enabled
   workspace Investor Context and an exact explicitly invoked `$strategy-*`
   before Head Manager dispatches any role
@@ -815,7 +817,7 @@ stop without an order, approval, execution, cancellation, broker mutation, or
 secret action. Record an unavailable Codex/auth blocker rather than replacing this with a
 claim based only on the fake subprocess test.
 
-Reference acceptance uses Codex CLI 0.144.4. Run
+Reference acceptance uses Codex CLI 0.145.0. Run
 `python tests/codex_cli_contract.py --workspace <workspace>
 --require-reference --require-hook-trust` first, after opening the disposable
 workspace in interactive Codex and persistently trusting all five generated
@@ -825,7 +827,7 @@ configuration, readable sandbox settings, the expected enabled/disabled
 feature states, and trusted lifecycle hooks. Native `codex exec` smokes must
 also pass `--strict-config`, so a newly unknown or removed project key fails
 before model behavior is accepted. Do not use `--ignore-user-config` or
-`--dangerously-bypass-hook-trust` for lifecycle acceptance: in 0.144.4 the
+`--dangerously-bypass-hook-trust` for lifecycle acceptance: in 0.145.0 the
 one-run bypass is not inherited when a V2 child reloads an exact role config.
 On platforms where a temporary directory has a symlinked alias, resolve the
 workspace once with `realpath` or `Path.resolve()` and use that same physical
@@ -838,10 +840,13 @@ Run native CLI smokes that inspect observable tool calls and child lifecycle
 results from Codex. Cover the direct fast path, one exact profile, a same-owner
 `followup_task`, and a bounded evidence-role generic fallback when a profile is
 unavailable. Briefs must stay compact, generated TOML must retain the fixed
-model settings and the project-wide `trading-research` profile, and no child may
-recursively delegate. A missing independent risk or judgment profile must remain
-explicit rather than becoming a generic review. Run a sequential two-child smoke plus one artifact-to-synthesis
-workflow because lifecycle failures may appear only after the first child exits.
+model settings and the project-wide `trading-research` profile. When native
+Codex delegates a child-owned subtask further, inspect the descendant lifecycle
+and verify that its effective role, model, permission profile, MCP principal,
+evidence boundary, and no-order boundary match the selected role. A missing independent risk or judgment
+profile must remain explicit rather than becoming a generic review. Run a
+sequential two-child smoke plus one artifact-to-synthesis workflow because
+lifecycle failures may appear only after the first child exits.
 
 For a full research smoke, inspect root and child JSONL as observable behavior,
 not private chain of thought. Require a compact bounded child brief; reject broad
@@ -923,7 +928,10 @@ Also install the built wheel in a clean environment and run:
 
 ```bash
 python tests/platform_wheel_smoke.py --wheel-dir dist
-python tests/release_upgrade_smoke.py --wheel-dir dist --from-version 1.0.2
+python tests/release_upgrade_smoke.py --wheel-dir dist
 ```
 
+The upgrade smoke selects only the latest stable PyPI release preceding the
+candidate version. Historical release pairs are not replayed by default.
+
 Detailed release workflow lives in [deployment.md](./deployment.md).