Repository navigation
Research native T3 usage and limits by project/environment; adopt Foundation defaults #35
Description
Undersøgelsen, den praktiske Foundation-vejledning og adoptionen er afsluttet i Factory 0.1.14. Det leverede resultat genbruges; ingen ny prøve eller installation.
Den manglende native projekt-/threadmåling er flyttet til #32 som ventende platformafhængighed med den eksisterende upstream-diskussion. Funktionen er ikke leveret. Environmentfiltre giver hverken OS-isolation, flere providerkvoter eller faktisk projektpris.
Tidligere scope og status — bevaret ved konsolidering 15. oktober
Undersøgelsen og Factory-vejledningen er leveret i 0.1.14 og installeret i de eksisterende skill-profiler. Resultat og konkret eksempel.
#35 står fortsat åben for den manglende native projektopdeling. Den er meldt i den eksisterende T3-diskussion; Factory AgentOps genbesøger den ved en relevant understøttet opdatering. Flere environments giver ikke i sig selv projektregnskab, flere kontokvoter eller OS-isolering.
Den accepterede opgave — 15. oktober 2026
The owner wants to inspect native T3 Code usage and limits by project and by environment, including a useful view of a project's cumulative consumption. The current UI was reported to show an environment selector but no obvious project-level breakdown; this is an owner observation, not a verified missing feature.
Research and supported native setup are authorized. Factory AgentOps owns this task and any resulting Foundation guidance through the existing review/delivery process.
Acceptance:
- Inspect the installed T3 version, actual usage UI/settings, official source/docs and existing upstream requests. Show which environment, project, thread, provider/account and time-range filters actually exist.
- Distinguish recorded tokens/usage, provider-account quota/reset windows, estimated API-equivalent cost and actual billed/subscription cost. Do not invent retrospective project spend, allocate a shared account quota to a project without evidence, or present missing data as zero.
- If supported, configure the smallest native setup and demonstrate a meaningful project/environment readback. Preserve access and account boundaries; no new paid service, billing change, credential copy or expanded grants.
- Make the supported setup and its honest limits a normal, proportionate part of Factory Foundation and the existing adoption record. Verify the guidance on an actual project, with independent review of any method changes. An unsupported feature stays conditional rather than making all onboarding fail.
- If the native feature is absent, deduplicate upstream issues and file or contribute a concise, evidence-backed T3 Code feature request. Link it here and park only the unsupported remainder. Do not promise an upstream release.
- Return the actual navigation path, verified available metrics, remaining limitations and ownership for upkeep.
Keep this at the native T3/harness layer. Do not build a Factory metering service, cost database, dashboard, proxy or custom T3 patch. No repeated polling/requalification of unchanged evidence.
Related: #7 contains earlier native model/usage qualification; reuse applicable evidence without treating it as proof of project-level accounting. Existing product priorities continue; Kastanje remains excluded.
Activity
gustavonline commentedon Oct 15, 2026
Owner clarification: the usage UI appears to offer filtering by environment, while all current projects share one saved environment. Treat this as a concrete hypothesis to verify, not proof that project-level attribution is unavailable.
Research the native relationship between machine, server/service instance, environment/connection, project and provider account. Verify whether multiple environments can live on the same machine, whether one environment per project is a supported and proportionate configuration, and what that actually separates: recorded usage, history/configuration, provider quota, credentials and execution boundaries may have different scopes.
Prefer a native project filter or project attribution if available. If environment-level accounting is the only option, assess the actual setup and upkeep cost, worker/history preservation, and whether quota/billing still belongs to a shared provider account. Separate reporting is not proof of separate billing or OS isolation.
Return the least-maintenance supported choice with evidence and make the verified guidance part of Foundation. Do not create or migrate environments merely to test this hypothesis, duplicate provider logins, change billing or build an accounting layer. Missing native capability should become a deduplicated upstream request and a bounded gap.
The owner also raises an access-control hypothesis, linked to #32 and #33: could native environments give different projects genuinely different permission/isolation boundaries? Investigate where effective policy is applied (environment/service, provider profile/account, project, thread/tool sandbox and OS identity). Establish whether separation is enforced or only separates UI/history/configuration. A more-privileged environment must not automatically become a general approval authority or make shared credentials safe. Reuse existing boundary evidence and only qualify relevant native controls within current authority. This is a question to validate, not authorization to grant more rights, move projects, share credentials or introduce a new isolation layer. If the hypothesis does not fit T3's architecture, explain that plainly and retain the simplest supported setup.
gustavonline commentedon Oct 15, 2026
Vi har kontrolleret T3’s forbrugsvisning i den installerede Mac-app. Den viser tokenforbrug, prisestimater og abonnementernes grænser, men den fordeler ikke forbruget på projekter.
Før sagde Foundation-guiden blot, at forbrug kunne ses i T3. Guiden på main forklarer nu, hvor du finder tallene, og hvorfor et ekstra environment med samme konto hverken giver et selvstændigt projektregnskab eller en ny sikkerhedsgrænse.
Pakkecheck og 11 tests bestod. Guiden er uafhængigt gennemgået, merget i PR #37 og nu udgivet og installeret med Factory 0.1.14. Både PR- og main-CI er grøn. Kvotetallenes friskhed er ikke uafhængigt kontrolleret. Vi følger den eksisterende upstream-sag om projektopdeling.
Kontrol, kilder og begrænsninger — 15. oktober
Den eksisterende Mac-operatør observerede Nightly3010/d83929ad i About og brugte den native Usage-knap. Den eneste environment udgjorde hele udvalget og blev derfor vist som “All environments”. Cost/Tokens/Limits, 24h/7d/30d/90d, Codex/Claude Code og Model/Day blev observeret. Ingen projekt-, thread- eller account-filtre blev observeret. Cost siger “API estimate” og viser unpriced usage. Limits viser resetvinduer; historikperioderne er deaktiverede. Ingen stale/unknown/error-markering var synlig, men heller intet entydigt datatidsstempel. Visning og filtre blev gendannet; ingen tvungen refresh, reset, settings, konti eller rettigheder blev ændret.
T3’s usage-vejledning og usage-kontrakten blev læst separat. De beskriver providerhistorik, også uden for T3, med deduplikering af fælles kilder og konti. Tokens, API-prisestimater, faktisk betaling og kontokvoter er forskellige mål; manglende data er ukendte, ikke nul. Der er ikke beregnet en retrospektiv projektpris.
Flere environments kan dele maskine og stadig have hver sin T3-identitet, konfiguration og klientadgang. De kan samtidig dele OS-konto og providerhistorik. T3’s adgangsmodel gør ikke et projekt til en filesystem-sandbox. #32/#33’s faktiske grænser gælder fortsat. Der er ikke oprettet eller flyttet environments/profiler.
De oprindelige fem kildefiler og ni staged Foundation-filer er gennemgået. Efter udgivelsen blev de fire ændrede, eksisterende skill-filer installeret i begge eksisterende profiler: otte filudskiftninger, med alle 48 valgte filer kontrolleret og tidligere bytes gemt til tilbageførsel. Leaden læste den installerede vejledning eksplicit; automatisk genindlæsning i allerede kørende workers er ikke påstået. Ingen settings, rettigheder, credentials eller nye skill-rødder blev ændret. Den sidste ændring tilføjer kun den attribuerede UI-observation til kvalifikationsrækken; uændrede unit/staging-checks er videreført på identiske inputs. Første review læste intet på grund af en tilladelsesprompt og blev afbrudt sikkert. Det gennemførte R2-review accepterede den præcise guide og observerede ingen permission-hold eller denial. Det brugte den eksisterende native Codex-sandbox/auto-review-profil; det er ikke aktiveret AgentOps-godkendelsesmyndighed. R1 gav intet kildeverdict; den misvisende formulering i en tidligere testkvittering er korrigeret særskilt uden at overskrive kvitteringen.
PR15902 var åben og unmerged ved readback. Den eksisterende diskussion er genbrugt; ingen dublet, custom regnskabslag eller upstream-adoption. Factory AgentOps genbesøger den manglende projektopdeling efter en relevant understøttet T3-opdatering. #35 står kun åben for denne native restfunktion; undersøgelsen og den lokale vejledning er leveret.