6.4 KiB
Increment 2 charter (#1500)
Status: owner APPROVED the fixture-only implementation after prerequisite correction was independently verified and published. Implementation baseline: 27e4873acc. Original draft and prerequisite context follow.
Baseline b3fa221060. Owner requested faster continuation of charter drafting. Author/coordinator Darkwing; independent reviewer Filbert; Jason approves implementation. The subsequent owner approval authorizes only the fixture-only stages and allowed paths below; no live activation is included.
Outcome and boundary
Prove that two executions of one agent can resolve different authorized accounts and generate isolated Pi inputs without sharing mutable files, emitting secrets, or silently switching identity. Exercise the owner-selected pi auth check --provider <p> refresh-driver contract with a fake executable and synthetic credentials only. No live secrets, OAuth traffic, timers, deployment, launcher integration, package upgrades or Ollama installation.
Prerequisite gate: do not build on unverified safety
The first increment's fifteen tests establish their assertions, not comprehensive registry safety. Baseline source inspection raises these concrete checks before materialization may begin:
- loadRegistry's safeList catches every directory error and returns an empty list. Missing/inaccessible roots must not validate successfully.
- stat follows symlinks; metadata reads need path containment, regular-file and permission checks before reading. Credential paths must never be traversed by list/validate.
- Record versions currently use an ID-string validator despite numeric versions in the governing plan. Resolve schema/fixture consistency, unknown versions and nested unknown keys.
- Default account must be enrolled in allowedAccounts and match its provider's supported credential types. Validate every custom endpoint, not only its pi entry; reject URL credentials and unsafe protocols.
- Malformed input must yield bounded secret-free errors, not raw JSON parse excerpts or partially trusted list output.
Reviewer independently reproduces these with fixtures in a disposable copy. Any confirmed prerequisite defect blocks materialization. Return a separate narrowly chartered correction first if the repairs cannot fit a small, independently reviewable patch. Prior approval is not a waiver of a new demonstrated defect.
Proposed stages after owner approval
- Close verified prerequisite defects, obtain independent approval and clean-tree regression evidence before dependent work.
- Pure resolution: explicit agent/project/workspace/session/execution and profile/account references. Enforce enrollment and fork account pins; unpinned relaunch uses the approved default. Missing or revoked pins refuse, never fall back. Exact field additions remain subject to review against #53; do not implement its full runtime object model.
- Materialize synthetic credentials through an injected storage interface into a new execution-owned generation directory. Separate auth.json, models.json and non-secret manifest; no credential hashes in the manifest. Private directories/files, no symlink following, exclusive creation, validate full generation before making it visible. Failed generation leaves prior usable inputs unchanged. No shared mutable per-seat generated files.
- Refresh adapter boundary: invoke the selected command with an explicitly isolated auth location and fixed arguments, excluding
--credentialsand print commands. Fake Pi simulates expired/valid credentials, rotated refresh tokens, errors and timeout. Token-bearing output must never reach logs; failures refuse and are recorded without secrets. Provider-specific refresh behavior and arbitrary code/extension loading must not be assumed safe from CLI command naming alone. - Independently review exact candidate, run applicable suites in an isolated committed-tree copy, selectively publish only after approval and green applicable checks. Present fixture-only demonstration to Jason before increment 3.
Allowed implementation paths, only if approved
packages/mosaic/src/, packages/mosaic/tests/, packages/mosaic/package.json, package documentation and this assignment's task/review records. Do not silently broaden schema or dependency authority. No new dependency or root config edit without a reviewed need. Existing scripts/auth.sh, launcher scripts, native homes, dataRoot, services, images and releases remain unchanged.
Acceptance and negative controls
- Missing/inaccessible/symlinked registry roots, metadata files and traversal attempts refuse before external reads; capture fake-marker disclosure tests for stdout/stderr/errors.
- Unsupported numeric versions, nested unknown fields, malformed/null records, cross-provider references, unenrolled defaults and credential-type mismatches refuse.
- Concurrent execution fixtures use distinct immutable generations; a fork cannot adopt a different account; no cross-execution file replacement.
- Generation failure, credential rotation, lock contention, timeout and interrupted output preserve prior good inputs or report uncertainty without blind retry.
- No network or real credentials in tests. Verify fake refresh command arguments, isolated auth location, environment allowlist and no inherited native extensions/config. If the supported Pi isolation boundary cannot be proven, stop rather than use the default auth home.
- Applicable package/config/auth/task/release/conductor/foundation/launcher suites green from clean candidate copies. Prior task-suite headless failure requires environment/root-cause reconciliation, not a permanent baseline waiver. Never stash unrelated work to create a test baseline.
- A build or release performed internally by a suite still counts as an effect; inspect tests first and use isolated state and explicit authorization rather than assuming a test name grants permission.
Rollback and completion
Source revert restores the previous implementation; synthetic temporary directories are cleaned by tests. No runtime migration or live rollback is needed because none is performed. A production secret backend, refresh service and deployment require later explicit charters.
This draft does not certify increment 1 or infer acceptance from a valid smoke-test response. Previous records labeled that response acceptance more strongly than Jason's words warranted; do not use that label to skip any technical prerequisite or the owner approval requested here.