Repository navigation
[BUG] Clean grok-cloud install fails audit after replay selects a different target #2816
Description
Describe the bug
A clean local skill installed with --target grok-cloud fails apm audit --ci: audit replays the skill into Copilot's .agents/skills/ tree and reports that unrelated location as unintegrated, although the installed .grok/skills/ file and lockfile agree.
An unrelated .github/workflows/ file supplies a target-detection signal. Saving apm config set target grok-cloud does not correct audit replay. The usual durable-target workaround, targets: [grok-cloud] in the consumer manifest, is explicitly rejected by manifest parsing even after experimental enablement. This leaves an unresolved install/audit target-contract mismatch; it is not evidence of actual content tampering.
To Reproduce
Use a disposable consumer directory and isolated HOME.
- Create a local skill package at an absolute path
/ABS/package:
package/
apm.yml
skills/example/SKILL.md
apm.yml:
name: example-package
version: 0.1.0skills/example/SKILL.md:
---
name: example
description: Experimental target audit reproduction
---
# Clean source content- Create the consumer's
apm.yml, substituting the actual absolute package path:
name: consumer
version: 0.1.0
dependencies:
apm:
- path: /ABS/package- Add an unrelated
.github/workflows/unrelated.ymlfile to the consumer (for example,name: unrelated). Do not author a Copilot skill or request a Copilot deployment. - Run:
apm experimental enable grok-cloud
apm config set target grok-cloud
apm install --target grok-cloud --no-policy --parallel-downloads 0
apm audit --ci --no-policy --format json- Install exits 0, writes
.grok/skills/example/SKILL.md, and recordsgrok-clouddeployment ownership and the matching content hash. Audit exits 1 because replay expects.agents/skills/example/SKILL.mdinstead.
Additional diagnostic control: declaring targets: [grok-cloud] in the consumer manifest makes install exit 2 with Unknown target 'grok-cloud', despite the enabled flag. That unsuccessful fixture workaround was not retained in the interaction regression.
Expected behavior
A clean installed target should round-trip through audit without false drift caused by an unrelated harness-directory signal. Define a consistent target-intent contract for experimental targets across install and audit, including how manifest restrictions, explicit installation targets, configured defaults, and deployment ownership interact.
Do not suppress the drift check, discard ownership assertions, or broadly ignore experimental-target findings to make the case pass.
Environment (please complete the following information):
- OS: macOS
- Python Version: 3.12.10, locked development dependencies
- APM Version: 0.29.1, source commit
23e921750e5bdb25d02c7b0c71a6b97bd7b851ac, editable installed CLI - VSCode Version (if relevant): N/A
Logs
The real fixture uses a longer unique skill name; the relevant audit output is:
{
"passed": false,
"checks": [
{
"name": "content-integrity",
"passed": true,
"message": "No critical hidden Unicode or hash drift detected"
},
{
"name": "drift",
"passed": false,
"message": "drift detected: 1 file(s): .agents/skills/example/SKILL.md",
"details": ["unintegrated: .agents/skills/example/SKILL.md"]
}
]
}The actual result has ten checks: all nine non-drift checks pass, including ref consistency, deployment-ledger owners, deployed-file presence, and content integrity.
Additional context
Discovered while independently hardening APMLifecycle after #2809 / during rework of #2813. The unskipped, locally reproduced interaction is tests/integration/test_primitive_target_covering_array.py::test_primitive_target_covering_array[interaction-b8852029871d9058] in the current not-yet-published test-only worktree. The final four-shard run reproduces the failure, and the combined evidence gate correctly refuses to credit its interaction pairs.
Source boundaries at the tested commit: install/drift.py::_read_apm_yml_target and run_replay select replay targets from the manifest or detection; core/apm_yml.py::_validate_canonical rejects experimental capabilities in manifest target fields. reference/cli/config.md currently documents the configured default as an install/update setting, so simply assuming audit already promises to honor it is not a fix or a sufficient contract analysis.
Generalized properties: routing.authorized_targets_only, outcome.status_matches_state, clean install/audit consistency. Production changes and Phase 3 transaction redesign remain separately approval-gated.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
fix(audit): replay canonical current target intent
fix(audit): keep native replay and discovery read-only
github-actions commentedon Sep 9, 2026
Triage decision
accept
Proposed labels
Milestone
null -- open-milestone read failed (401 from milestones API); no milestone assigned this run.
Suggested next action
Define the target-intent contract for experimental targets across install and audit (manifest target restriction, explicit --target, configured default, and deployment ownership) and align audit replay to it.
Suggested issue comment
Per-lens notes (collapsed)
DevX UX Expert -- User-Need Reviewer
A clean install that then fails its own audit for an unrelated, correctly-installed file breaks user trust in
apm audit --cias a reliable gate, especially since the documented workaround (config set target) doesn't fix replay.Supply Chain Security Expert -- Risk-Surface Reviewer
No new risk surface; this is a target-selection contract inconsistency between install and audit, not a trust boundary issue.
OSS Growth Hacker -- Contributor-Tone Reviewer
Not activated -- danielmeppiel is a maintainer-level reporter with many prior interactions on this repo.
Python Architect -- Architecture Reviewer
The issue explicitly names an open contract decision (how manifest restrictions, --target, configured default, and deployment ownership interact for experimental targets) -- a real cross-cutting design question, but the issue is already status/accepted and shepherded, so I'm not overriding to needs-design; noting the contract decision in next_action instead.
Doc Writer -- Documentation Reviewer
reference/cli/config.md should be updated once the target-intent contract is settled, since the reporter notes the current doc text doesn't already promise audit honors the configured default.
APM CEO -- Triage Arbiter
Already accepted and shepherded -- ratifying, adding taxonomy labels and status/triaged. No milestone change this run (milestone read failed).
{ "decision": "accept", "decision_detail": "Already status/accepted and in shepherding; taxonomy labels added.", "theme": "theme/portability", "areas": ["area/multi-target"], "type": "type/bug", "status": "status/accepted", "priority": null, "preserved_labels": [], "milestone": null, "next_action": "Define the target-intent contract for experimental targets across install and audit (manifest target restriction, explicit --target, configured default, and deployment ownership) and align audit replay to it.", "comment_markdown": "Already accepted and in shepherding -- adding taxonomy labels (theme/portability, area/multi-target) and status/triaged. The core ask -- a single, consistent target-intent contract shared by install and audit for experimental targets -- matches the framing already in this report." }github-actions commentedon Sep 10, 2026
Triage decision
accept
Proposed labels
Milestone
null
Suggested next action
Fix
apm audit --citarget-detection so a clean install with an explicit--target grok-cloud(and its resulting lockfile/native-deployment agreement) is not overridden by an unrelated signal (e.g..github/workflows/), and reconcile withapm config set targetand the experimentaltargets:manifest key.Suggested issue comment
Per-lens notes (collapsed)
DevX UX Expert -- User-Need Reviewer
A clean, correctly-installed skill failing
apm audit --cidue to an unrelated file is a serious trust/DX problem -- audit is supposed to be the source of truth for "did the install match the lockfile," and false-positive failures erode confidence in the whole audit gate.Supply Chain Security Expert -- Risk-Surface Reviewer
Directly touches audit/integrity verification (area/multi-target overlaps content-integrity concerns here). Important that the fix narrows target-detection precision without weakening audit's ability to catch genuine tampering -- the report is careful to state this is a contract mismatch, not a security regression.
OSS Growth Hacker -- Contributor-Tone Reviewer
Not activated -- author_association is COLLABORATOR.
Python Architect -- Architecture Reviewer
Not activated -- bounded fix to target-detection heuristics in the audit replay path; no new interface or schema required, though the durable-target workaround gap (targets: rejection under experimental) may warrant a follow-up issue if it recurs.
Doc Writer -- Documentation Reviewer
Not activated -- no doc surface change implied beyond existing audit/target docs.
APM CEO -- Triage Arbiter
Clear correctness bug from a trusted collaborator with full repro steps. Accepting as theme/portability, area/multi-target, type/bug; already marked status/shepherding so keeping status/accepted.
{ "decision": "accept", "decision_detail": "", "theme": "theme/portability", "areas": ["area/multi-target"], "type": "type/bug", "status": "status/accepted", "priority": null, "preserved_labels": [], "milestone": null, "next_action": "Fix apm audit --ci target-detection so a clean install with an explicit --target grok-cloud is not overridden by an unrelated signal, and reconcile with apm config set target and the experimental targets: manifest key.", "comment_markdown": "Confirmed -- this is a real install/audit target-contract mismatch, not evidence of tampering. Audit replay is picking up an unrelated Copilot-detection signal instead of honoring the explicit --target grok-cloud that produced a consistent install + lockfile state. apm config set target and the experimental targets: manifest key don't correct this either. Accepted as a bug; the fix should make audit replay durably honor the recorded install target." }danielmeppiel commentedon Sep 12, 2026
At the lead maintainer's direction, the current acceptance of this item is withdrawn as part of APM's roadmap and contribution reset. Previous acceptance labels or comments must not be treated as approval to start or continue substantive implementation for inclusion in APM.
Thank you for the work and ideas already contributed. Our small maintainer team needs to agree supported scope and review capacity before inviting more implementation. This is not a rejection of the proposal or a judgment of your work, and it does not undo completed work or erase its history.
Please follow the contribution rules: a responsible human maintainer needs to record the bounded scope, acceptance criteria and review contact on the issue before substantive work resumes. Existing issue discussion, assignments and contributions remain available for that decision. Trivial typo and broken-link corrections retain their standing preapproval.
danielmeppiel commentedon Oct 19, 2026
Decision: approve
Area: project
Scope: Repair the reproduced disagreement between an explicit Grok Cloud skill installation and audit target selection, so unrelated harness-directory signals do not make a clean requested installation fail audit. Use the existing canonical target-selection, deployment and replay owners to reconcile current declared intent with recorded deployment ownership; preserve legitimate requested target changes, configured-default semantics and experimental opt-in.
Done when: Current-source installed-CLI coverage reproduces the workflow-triggered false Copilot drift and demonstrates correct install/clean audit and reinstall/clean audit, with independent path, byte, hash and target-ownership assertions. Cover the unrelated workflow signal, the no-workflow and stable-target controls, current target-intent changes, and disabled-experiment boundaries. Genuinely missing or modified managed files still fail meaningfully. Audit preserves project, lockfile, source package, live cache and harness state apart from an explicitly requested report. Reuse existing lifecycle coverage and update directly related guidance; refresh the reproduction against the implementation head.
Out of scope: Experimental-target promotion, new targets, broad target-precedence or ownership/schema redesign, new manifest or CLI contracts without a separately identified and approved scope delta, blindly trusting old lock state over current intent, audit exemptions or suppressed drift, assignment or relationship changes, reopening historical PRs, release promises, automated implementation dispatch or restarting blocked delivery.
Review contact: Daniel Meppiel (@danielmeppiel)
danielmeppiel commentedon Oct 19, 2026
Accepted: bounded install/audit target consistency repair
Following explicit maintainer confirmation, the bounded repair is accepted, with Daniel Meppiel (@danielmeppiel) as review contact.
The report still reproduces on main
cb06ec21bafd58bc8eb8961d7f4cf6843c604809, APM 0.34.0, macOS arm64 and Python 3.12.10. Using the real installed CLI with isolated home, configuration, cache and local fixtures:.github/workflows/unrelated.yml, audit exits 1 solely because it expects an unrequested.agents/skills/example/SKILL.md. Reinstalling does not resolve it.Unknown target 'grok-cloud'after experimental enablement.This is evidence of an install/checker disagreement, not damaged installed content. The passing Grok control does not prove correct target identity either: audit attributes its
.grokskill coverage to Grok Build while the ledger records Grok Cloud.Fix the demonstrated mismatch through the existing canonical owners. Preserve current intended targets and real drift checks rather than blindly replaying stale lock state or exempting experimental deployments. Keep Grok Cloud experimental and opt-in. The observed manifest restriction is not automatic approval to introduce a new manifest contract.
The evidence is macOS installed-CLI coverage, not a cross-platform matrix, native Grok execution or complete CI result. Refresh it against the implementation head and satisfy the bounded scope record's remaining checks.
The issue stays open and the existing assignment is unchanged. This supersedes the earlier withdrawal only for the newly recorded scope; it does not reopen #2813, #2919 or #2923, start automated delivery, or promise a release.
Generated by apm-strategy. This comment is AI-generated and may contain errors.
fix(audit): preserve Grok Cloud target identity and historical checks (…
danielmeppiel commentedon Oct 20, 2026
Resolved by #3289
PR #3289 merged in
942a3328e46c1283c8c76afd9206b889afd2012cand completes the accepted install/audit consistency repair.The merged repair preserves explicit Grok Cloud deployment identity despite unrelated workflow-directory signals, honors current target intent, checks retained historical files, and preserves experimental opt-in and real missing/modified-file failures. Installed-CLI coverage includes install/audit, reinstall/audit, target changes and non-mutation; the final review also qualified legacy-ledger discovery.
The PR used a non-closing
Issue: #2816reference. Keeping this issue open after the completed repair was a bookkeeping error, not an outstanding accepted requirement. Closing it as completed now, at the maintainer's request to correct campaign status.This does not promote Grok Cloud, introduce experimental manifest syntax, or claim native Grok runtime qualification. Those were not requirements of the accepted repair.
Generated by autopilot-pr-merge-worker. This comment is AI-generated and may contain errors.