Skip to content

docs(plan): #346 U4 native context export design - #349

Merged
Ancienttwo merged 1 commit into
mainfrom
codex/issue-346-u4-native-export-plan-public
Oct 14, 2026
Merged

Ancienttwo merged 1 commit into
mainfrom
codex/issue-346-u4-native-export-plan-public

Conversation

@Ancienttwo

Copy link
Copy Markdown
Owner

Refs #346

This docs-only plan defines a stateless native context export for repo-harness readers: archctx export native --worktree or --ref <commit-ish>, with profile repo-harness/v1. It changes only plans/plan-20261014-1325-issue-346-u4-native-context-export.md; the product API is not implemented by this PR.

The reviewed plan fixes three bounded issues:

  • Declared contract paths remain required, while safely missing files return explicit presence and null text/byte metadata. Missing paths remain in the input digest and read-stability observations; unsafe or unreadable existing files still fail.
  • Duplicate-key ambiguity detection covers every object-construction path in the shared parser, including whole JSON, inline/nested JSON containers and escaped-equivalent keys. This does not authorize a general YAML rewrite.
  • Native validation follows canonical type/pattern/minLength/required constraints and preserves schema-valid empty component summaries and relation intents. Capability-profile restrictions are stated separately.

Parser compatibility remains to be verified against frozen repo-harness source/value fixtures. Unsupported constructs or value mismatches block the corresponding consumer coverage confirmation; this document does not claim corpus/value parity has passed.

Implementation gates:

The plan retains fixed Git-blob reads, source-path safety, lossless human document regions, typed errors and the lock-free worktree ABA limitation. It makes no release/version commitment and does not close #346.

Validation: document consistency/scope checks and git diff --check passed. Product tests were not run because this PR contains only the plan. Draft for design review; product implementation begins only after the listed gates are satisfied.

@Ancienttwo
Ancienttwo marked this pull request as ready for review October 14, 2026 10:28
@Ancienttwo
Ancienttwo merged commit c2bd0be into main Oct 14, 2026
12 checks passed
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 14, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-14T10:33:31.839613Z aadb427 Draft marked ready
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: aadb427c79

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

- all step/outcome from/to/terminal references name declared participants; outcome IDs are unambiguous; repeated step identities cannot disagree about their definition;
- entrypointId/sourceSymbol/sinkId references resolve to a declared model selector tuple, including outcome steps. This checks declaration integrity only, never code-symbol existence or P2 proof;
- all model path-bearing fields and profile/doc/contract paths obey repository-relative POSIX safety. Reject absolute/drive/UNC paths, backslashes, controls, empty/dot/parent segments and escaping aliases. Validate globs without changing the canonical * / ? ownership grammar;
- separately declared repo-harness/v1 profile restrictions: a capability uses the three-part capability.<domain>.<name> identity accepted by parseRepoHarnessNodeProfile; both explicit contract path declarations are nonempty safe paths ending in the appropriate AGENTS.md/CLAUDE.md basename; derived module paths are unique; a declared lspProfile is a nonempty string, and declared verification is an array of strings (empty array allowed). Undeclared lspProfile/verification remain null. These restrictions do not make all native node names/summaries or relation intents nonempty, require contract file existence, or modify optional native fields/shared declarations.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Treat malformed optional profile metadata as absent

When a capability has a non-string extensions.lspProfile or non-array extensions.verification, this restriction makes the entire export fail. However, docs/adr/ADR-0043-agent-context-provider.md:73-74 explicitly requires adapters to treat malformed values for these convention-only fields as absent until a later ADR promotes them to validated schema fields. Because this plan neither amends nor supersedes that ADR, the native reader would reject canonical models that existing adapters must accept; export these values as null, or explicitly include the required contract promotion in scope.

Useful? React with 👍 / 👎.

- every parent exists and every parent chain is acyclic (including self cycles);
- every relation source/target and optional via references an existing node;
- every flow capabilityId names a capability; participant IDs are unique within a flow and each participant's nodeId exists;
- all step/outcome from/to/terminal references name declared participants; outcome IDs are unambiguous; repeated step identities cannot disagree about their definition;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Validate each flow step against a declared relation

For a required flow whose from and to participants both exist but whose node IDs have no connecting model relation, every invariant listed here passes. The existing semantic compiler checks exactly this case in packages/core/projection-engine/src/semantic-diagrams.ts:314-320 and reports relation-binding-missing, so the export could claim a fully validated model while ArchContext treats the same P2 flow as unprovable. Add the same directed relation-binding invariant, including outcome steps, and cover it in the model-completeness tests.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

U4 (#690): Confirm context/export/agent-context cover repo-harness model readers

1 participant