fix: Comet Native's baseline snapshot manifest cap

[aamkye]

🔎 Existing issue check

• I have searched the existing issues.

🎯 Affected area

Workflow contract (domains/workflow-contract)

📦 Comet version

4.0.0-beta7

💥 Current behavior

I've encountered the following error while preparing changes with OKF:

Confirmed the blocker is structural and non-configurable:
- At new time the runtime calls createNativeContentSnapshot with no denylist (line 13624-13627), and there is no per-project exclude mechanism — only a hardcoded directory set (node_modules, .git, etc.) that doesn't include okf_bundle.
- The config schema (comet.project.v1) accepts only artifact_root/language/clarification_mode — no limits knob — and there's no env override.
- The 7,823-file okf_bundle/ pushes the baseline manifest past the 1 MB maxManifestBytes cap → entries get folded into "omitted" → baseline.complete=false → NativeBaselineIncompleteError → change not created (exit 65). Removing okf_bundle leaves ~568 tracked files, which fits every limit.
So I cannot create the Native change without a repo-content change I shouldn't make unilaterally. This is a genuine decision for you.

✅ Expected behavior

The /comet-native can perform workflow.

🔁 Steps to reproduce

With GLM5.2:

1. okf generate . ./okf_bundle
2. in opencode: /comet-native create feature X

🖥️ Environment

- OS: Macos
- Shell: ZSH
- Node: 25.6.0
- Package manager: brew
- Install scope: project
- Skill language: en
- Target AI platform(s): OpenAI

📋 Logs or output

Confirmed: at new time (line 13624-13627), createNativeContentSnapshot is called with ONLY { now, origin } — no denylist is passed, so it defaults to [] (empty). The denylist is an internal option with NO project-config source (no .cometignore, no config field). So there's no way to exclude okf_bundle from the baseline via configuration.

So the situation is fully confirmed:
- Comet Native's new command builds a baseline content snapshot of all 8391 tracked files.
- The snapshot manifest exceeds maxManifestBytes (1MB) due to the 7823-file okf_bundle with long paths.
- The excess entries become "omitted" → baseline.complete = false → NativeBaselineIncompleteError thrown → change NOT created (exit 65).
- No config knob (artifact_root/language/clarification_mode only), no env override, no per-project denylist/exclude mechanism.

The ONLY ways to make the baseline fit:
1. Reduce the tracked file count (untrack okf_bundle).
2. Or Comet can't be used for this repo (as-is).

This is a genuine tooling blocker requiring a user decision. I've exhausted the technical options.

Now let me present this to the user. Per sequential mode, this is the most upstream blocker (it gates whether Native tracking is even possible). I'll use the question tool.

Let me reconsider: should I ask the tooling question, or should I just inform the user and ask how to proceed in a more open way? The question tool requires structured options. Let me craft good options.

Actually — I realize I should double-check one thing: is the omission REALLY manifest-size? Line 13628 checks !baseline.complete and builds omittedByReason. The CLI output didn't show the reason breakdown. Let me reconsider whether I should verify by another means before presenting, so my explanation is accurate.

Given my analysis is robust (the only differentiator from the working external-merchant-api is okf_bundle size, and removing okf_bundle → 568 files → well within all limits), I'm confident the cause is the okf_bundle volume hitting a snapshot limit (manifest-size being the most likely). My recommendation (untrack okf_bundle) resolves it regardless of which specific sub-limit. I'll present it as "exceeds Comet's baseline snapshot limits" without over-claiming the exact sub-limit, which is accurate.

Now, the options for the user. Let me think about what's genuinely actionable:

Option A — Untrack okf_bundle to enable Native (Recommended).
git rm -r --cached okf_bundle + add okf_bundle/ to .gitignore. This conforms to the canonical AGENTS.md setup ("force-stage intended files hidden by ignore rules" implies okf_bundle is gitignored and only force-staged during regeneration). The bundle stays on disk and is regenerated locally; it just stops being version-controlled. Enables the Native workflow the user requested. Trade-off: large diff (7823 deletions from index), and the team loses the committed bundle unless they re-force-stage on regeneration. Note: this is a separate concern from issue #234 and would be its own commit.

Option B — Proceed with the fix outside Comet Native.
Implement issue #234 directly (normal TDD/review via the repo's Taskfile), skipping Native change-tracking. Pragmatic; avoids touching the committed okf_bundle. Trade-off: discards the Native workflow the user explicitly chose.

Option C — Keep okf_bundle tracked, use Comet Classic or manual tracking.
Maybe Classic workflow or a lighter tracking approach tolerates the large tree. But I'm not sure Classic has different limits. Uncertain.

Hmm, Option C is weak. Let me reconsider. Actually, the cleanest framing is A vs B, with A recommended (aligns with AGENTS.md and enables the chosen workflow).

Wait, but I should be careful about recommending untracking a committed artifact. Let me reconsider the recommendation. The user explicitly invoked /comet-native, so they value the Native workflow. Option A enables it. And AGENTS.md's canonical setup does treat okf_bundle as gitignored. So A is well-justified. But it's a notable repo change. I'll recommend A but clearly state the trade-off so the user can choose B if they prefer not to touch okf_bundle.

Actually — let me reconsider whether I even need to ask, or whether I should just inform and let the user steer. The Native skill is strict about asking only genuine user decisions and not burdening the user with implementation choices. Is "untrack okf_bundle vs skip Native" an implementation choice or a user decision? It changes: (a) the repo's committed surface (user/team-visible), (b) whether the chosen workflow is used. Both are user-visible. So it's a genuine user decision. I'll ask.

Let me also reconsider: maybe the user would want me to just do the fix and not fuss about Comet. But they explicitly invoked /comet-native, so I should honor that intent and surface the blocker rather than silently abandoning Native.

Let me present the question. One question, sequential mode. Clear options with the recommended one first.

Let me write a concise explanation + the question. I'll keep the explanation tight (the CLI display is monospace, concise).

Let me reconsider the options once more to make them crisp and mutually exclusive:

Q: Comet Native can't create a change in this repo — the committed okf_bundle/ (7,823 files) exceeds Native's baseline snapshot limit (1 MB manifest, not configurable; no per-project exclude). The working sibling external-merchant-api has a smaller bundle and tracks fine. How should I proceed?

1. Untrack okf_bundle/ to enable Native (Recommended) — git rm -r --cached okf_bundle + gitignore it. Matches AGENTS.md's canonical "gitignore + force-stage on regen" setup; bundle stays on disk, regenerated locally. Large index diff; separate commit from the #234 fix. Lets Native proceed.
2. Fix issue #234 without Comet Native — implement directly with the repo's Taskfile/TDD/review; skip Native change-tracking entirely. No repo-surface change; fastest path to the fix.
3. Shrink/refresh okf_bundle first — regenerate with the pinned generator; unlikely to shrink enough (it mirrors current code) and won't change the file count materially. Lower confidence this unblocks.

Option 3 is weak/low-confidence — maybe I should drop it and offer 2 clean options + the custom fallback. The question tool auto-adds "Type your own answer", so I don't need a catch-all. Let me give A and B as the two real options. Maybe add C as a third "investigate Comet upgrade/config further" but that's low-value.

Let me go with A (recommended) and B. Two clean options. The tool adds the custom option automatically.

Actually, the guidance says I can have more options. Let me give 3: A (untrack, recommended), B (skip Native), and maybe keep it to those two since they're the real fork. I'll do A and B.

Hmm, let me reconsider if there's a third legitimate path: ask the user if okf_bundle is even SUPPOSED to be committed. That's actually the key uncertainty. If the team intends it committed, A is wrong. If they intend it gitignored (per AGENTS.md canonical), A is right. 

Actually that's what option A vs B surfaces implicitly. But maybe I should make the question clearer about the uncertainty. Let me frame it as: "okf_bundle is currently committed (7,823 files) but AGENTS.md's canonical setup gitignores it. Native needs it out of the snapshot. How to proceed?"

Let me write the question now. I'll keep the preamble short since the question tool shows the question field.

Let me also make sure I'm not violating the protocol by asking a non-product question. The protocol is about product clarifications, but the skill ALSO says to resolve Runtime blockers and "Ask only when the missing input is genuinely a user decision." A tooling blocker that requires changing committed artifacts IS a genuine user decision. So it's appropriate.

One more consideration: the question tool's header is a short label. Let me make it concise.

🧩 Additional context

I had to add to the .gitignore:

# OKF knowledge bundle — regenerated locally by okf-generator. Untracked because the
# committed 7.8k-file bundle exceeds Comet Native's baseline snapshot manifest cap
# (1 MB, non-configurable), blocking `comet native new`. Re-stage with `git add -f`
# when publishing a refreshed bundle. See AGENTS.md "OKF Knowledge Bundles".
okf_bundle/

[aamkye]

With GPT5.6 Terra:

The requested change cannot be created: Comet’s baseline snapshot caps at 4,720 files, while this repository has 8,392 tracked files. It rejects the change with native-baseline-incomplete (3,672 omitted entries), so the Native workflow cannot safely proceed.

[benym]

I think this is the same issue as #226, and we are already working on it, expecting to fix it in the next version.