Explain T3 usage scopes and account limits

VERSION

@@ -1 +1 @@
-0.1.13
+0.1.14

docs/qualification.md

@@ -1,6 +1,6 @@
 # Qualification
 
-Revision: 0.1.13 · Updated: 2026-10-12
+Revision: 0.1.14 · Updated: 2026-10-15
 
 This record distinguishes source review, disposable exercises and observed native
 operation. A package release does not qualify another host, every future update
@@ -11,6 +11,7 @@ remain with the installation; public issues track the remaining acceptance work.
 | --- | --- | --- |
 | Package | Eight portable skills, metadata/link checks and staging tests | Mechanical checks do not establish agent decisions |
 | Foundation readiness handoff (0.1.12 candidate) | 2026-10-11: [Factory #27](https://github.com/arcitai/factory/issues/27) source change after an AIOS assessment accepted a stale mandatory authoring self-dependency, its disabled private reporting was found only by readback, its lead could not read its private record, and Project1's current README kept stale pre-delivery claims (coordinator observations, not reproduced here). Package, unit and staging checks only | Behavioral evidence and independent review are pending in the delivery PR. Native binding/authentication behavior stays with [Factory #3](https://github.com/arcitai/factory/issues/3); Markdown does not repair it |
+| Usage readiness (0.1.14 candidate) | 2026-10-15: [Factory #35](https://github.com/arcitai/factory/issues/35) source assessment of T3 upstream `d83929ad` usage docs, usage contract and environment-auth guidance (lead research, not reproduced here). The lead observed a native identity readback of the execution host's running server. The existing Mac operator then observed Usage in native Nightly 3010 (`d83929ad0bb0`) with one environment (selecting it still reads All environments): Cost, Tokens and Limits; 24 h/7 d/30 d/90 d history; Codex/Claude Code provider menu; Model or Day breakdown; no project, thread or account filter; Cost labeled an API estimate with unpriced usage itemized; Tokens as input, cache read, cache write and output; Limits showing account reset windows with history-period controls disabled. No refresh, reset, setting, account or billing change; the original view was restored | Limits showed no stale/unknown/error marker but no unambiguous as-of time, so quota freshness is not established. No project accounting, per-project quota, OS isolation or host adoption proof; upstream project attribution was unmerged at the 2026-10-15 readback. Package/unit/staging checks and independent review are tracked in the delivery PR |
 | Review check artifacts (0.1.13 candidate) | 2026-10-12: source change after an application operator reported (not reproduced here) that an OpenPaperDesign reviewer was told to modify no files yet asked to compile/test; Rust targets filled the shared `/tmp` quota, automatic approval refused cleanup under that instruction and the reviewer held without bypass. The operator later removed only an earlier completed task's rebuildable target after checking no process used it. Package, unit and staging checks only | Behavioral evidence for source-only, authorized-check-output and shared/active-artifact cases and independent review are recorded in the delivery PR. Project scratch setup stays with that project |
 | Persistent choices (0.1.10 candidate) | 2026-10-10: a fresh native Astra xhigh context answered four textual cases against `7f846946`: hypothetical settings stayed unauthorized; external read access retained scope and removal; provider-wide controls did not become project isolation; uncertain application, upgrade drift and expired exceptions required reconciliation | Method rehearsal, not live grant/revocation or a reliability measurement. Independent review of the combined source/presentation is tracked in the delivery PR |
 | Engineering Foundation (0.1.9) | 2026-10-10: [PR #24](https://github.com/arcitai/factory/pull/24) and release passed checks and independent review. The selected native scopes matched all 48 staged files; AgentOps explicitly reread the five changed Foundation files. AIOS' own AgentOps assessed its repository against the adopted method and actual build/review/pilot evidence | Explicit source loading is distinct from automatic instruction discovery. The optional three-hour CI profile has not been deployed or observed as a schedule; it enables no schedule itself |

foundation/factory-foundation/SKILL.md

@@ -3,8 +3,8 @@ name: factory-foundation
 description: Prepare or assess a software project's engineering foundation and its execution host, including reproducible setup, real checks, documentation, CI/delivery, native harness access and GitHub work tracking.
 license: MIT
 metadata:
-  version: "0.1.12"
-  updated: "2026-10-11"
+  version: "0.1.14"
+  updated: "2026-10-15"
 ---
 
 # Factory Foundation
@@ -53,6 +53,10 @@ Prepare only the chosen capabilities:
 - Confirm the native versions, selected provider account, effective tools and
   permissions. A discoverable binary or copied skill does not establish readiness.
   Record the project's small model profile from live native IDs and owner choices.
+- When using T3, read usage and limits in its native Usage view, as in
+  [the setup guide](references/setup.md#usage-and-limits). An environment there is
+  a view scope, not project accounting, quota or isolation; do not add environments
+  to obtain them.
 - Start AgentOps and workers with least privilege. Distinguish coordination
   authority from enforced OS/tool/credential access. For a wider grant, identify
   the required action, target, authorizer and removal condition; apply the smallest

foundation/factory-foundation/references/adoption.md

@@ -1,6 +1,6 @@
 # Adoption record
 
-Revision: 0.1.12 · Updated: 2026-10-11
+Revision: 0.1.14 · Updated: 2026-10-15
 
 Foundation identifies the appropriate existing project/adoption record and
 establishes the relevant choices. AgentOps maintains them and scoped exceptions
@@ -75,7 +75,8 @@ Reuse the following existing choice families only where they matter:
 - Routes to relevant architecture, checks, dependency/configuration sources and
   operational guidance. Preserve the project's existing names and records.
 - Execution host and OS identity, client route, service owner, native versions,
-  provider profiles and billing/usage source.
+  provider profiles and billing/usage source: the provider account and history it
+  covers, the native Usage view and filters used, known coverage gaps, and who reads it.
 - Model profile: a small editable default per role or kind of work, such as lead
   research, implementation, independent review and small mechanical work, with
   any concrete exception and its reason. Use live native provider, model and option

foundation/factory-foundation/references/setup.md

@@ -1,6 +1,6 @@
 # Set up the host and operator client
 
-Revision: 0.1.10 · Updated: 2026-10-10
+Revision: 0.1.14 · Updated: 2026-10-15
 
 This reference setup uses T3 Code on a Linux execution host, with a Mac and
 optionally a phone as clients. The host can be a laptop, workstation or VPS.
@@ -178,12 +178,63 @@ copying their credentials into a new location.
 
 Start with Codex and Claude if those are the selected subscriptions. Choose models
 from the actual provider catalog; use the owner's selection and measured results.
-Extra providers and automatic model routing are optional. Usage belongs in T3;
-API-equivalent estimates are not subscription charges and missing limits are unknown.
+Extra providers and automatic model routing are optional. Read usage and limits
+as described in [Usage and limits](#usage-and-limits).
 
 References: [Codex profiles](https://github.com/pingdotgg/t3code/blob/ec80933ac8cd02fec5c97b342462ccc9567cdb1e/docs/user/providers-codex.md),
-[Claude profiles and skills](https://github.com/pingdotgg/t3code/blob/ec80933ac8cd02fec5c97b342462ccc9567cdb1e/docs/user/providers-claude.md),
-[usage](https://github.com/pingdotgg/t3code/blob/ec80933ac8cd02fec5c97b342462ccc9567cdb1e/docs/user/usage.md).
+[Claude profiles and skills](https://github.com/pingdotgg/t3code/blob/ec80933ac8cd02fec5c97b342462ccc9567cdb1e/docs/user/providers-claude.md).
+
+### Usage and limits
+
+Assessed against T3 upstream `d83929ad`, 2026-10-15; read back the installed
+client's view before relying on it.
+
+Open **Usage** from the sidebar or command palette (`mod+U` when the terminal is
+not focused). Cost and Tokens show history over a 24 h, 7 d, 30 d or 90 d window;
+Limits shows each provider's own reset windows; the history-period controls are disabled there.
+Choose the environment (default: all) and inspect the provider/model breakdown and
+visibility each tab supports. These selections are local view preferences; they
+configure no billing, permission, quota or security policy.
+
+- Usage scans each configured provider's native history, including work outside
+  T3 and disabled accounts. Sources sharing one provider home, such as one
+  `CODEX_HOME` or `CLAUDE_CONFIG_DIR`, count once; use that deduplication rather
+  than adding totals across environments.
+- In the assessed pin, Usage has no project or thread attribution, and an
+  environment filter does not infer one. Do not estimate project cost retrospectively.
+  As of 2026-10-15 native project accounting is an open upstream
+  [proposal](https://github.com/pingdotgg/t3code/discussions/16722) and
+  [unmerged PR](https://github.com/pingdotgg/t3code/pull/15902); do not treat it as
+  installed, and recheck after a supported update.
+- Tokens are recorded units; reasoning is part of output, so do not add it twice.
+- Cost is an API-equivalent estimate where provider-reported or model-priced, not a
+  subscription charge; unpriced usage has no cost figure. Use the provider for actual
+  plans and charges: [Codex](https://learn.chatgpt.com/docs/pricing),
+  [Claude](https://code.claude.com/docs/en/costs).
+- Limits and resets belong to the provider account, not a project. One account used
+  by several environments is one allowance; do not sum it. `/usage-limits` reads
+  cached limits without starting a turn; refresh through the existing control.
+- Missing history, a stale scan or unavailable pricing or limits is unknown, not zero.
+
+Do not activate banked resets or paid overage, switch accounts or configure prices
+to produce a figure.
+
+A machine is the OS host; a server is the running T3 backend; an environment is
+that backend's identity, data and auth scope; a saved connection is one route to it;
+a project groups a repository or workspace; a provider account holds subscription,
+billing, history and authentication. Several environments on one host can have
+separate IDs, data and connection grants, yet still share the OS user and provider
+homes. Projects are not filesystem sandboxes: `filesystem:read` reaches what the
+server's OS user can read ([environment auth](https://github.com/pingdotgg/t3code/blob/d83929ad0bb0d4aec800f12c332de57e873cc7e5/docs/internals/environment-auth.md)).
+Keep the existing environment rather than adding one per project for accounting or
+isolation. Where a task genuinely needs separation, qualify a separate OS identity
+or protected native boundary as in [Choose the boundary](#1-choose-the-boundary);
+remaining approval and worker-boundary limits are tracked in
+[Factory #32](https://github.com/arcitai/factory/issues/32) and
+[#33](https://github.com/arcitai/factory/issues/33).
+
+Sources: [T3 usage](https://github.com/pingdotgg/t3code/blob/d83929ad0bb0d4aec800f12c332de57e873cc7e5/docs/user/usage.md),
+[usage contract](https://github.com/pingdotgg/t3code/blob/d83929ad0bb0d4aec800f12c332de57e873cc7e5/packages/contracts/src/usage.ts).
 
 ## 3. Make the service independent of the client