Mirror outstanding documented work into GitHub issues

[vycdev]

Goal

Mirror every genuinely outstanding work item documented in this repository into a GitHub issue so it is easier to assign, discuss, and track. Keep the documentation: issues are the execution/tracking layer, while the docs retain the fuller design context and project history.

This issue is the control record for the migration and the overnight operating brief for vycdev2.

Source order

Process sources in this order:

1. docs/active/*.md
2. docs/open_design/*.md
3. Entries marked Partial or Not started in docs/progress.md
4. Explicit future work, limitations, or unresolved decisions in docs/design.md and docs/architecture.md

Do not routinely create issues from docs/completed/. Those files are historical records. Only create an issue from one if repository inspection confirms that a specific item is still outstanding, and note that discrepancy in the issue.

Treat compatibility stubs, repeated summaries, and multiple docs describing the same work as references to one work item—not separate issues.

Nightly batch procedure

Create no more than 3 new work issues per run.

For each candidate:

1. Read the entire source note and any directly linked design/architecture context.
2. Inspect the current code and tests enough to confirm the work is still outstanding. Documentation can be stale.
3. Search open and closed issues by the key terms, affected subsystem, and source filename. Reuse or update an existing issue when it already tracks the same outcome.
4. Choose an independently completable unit of work:
   • Split a document when it contains multiple unrelated outcomes.
   • Keep tightly coupled implementation and tests together.
   • For an unresolved design choice, create a design-decision issue; do not invent the language behavior.
   • Avoid tiny checkbox issues that cannot be understood or completed independently.
5. Create the issue using the template below.
6. Add a direct Tracked by #<number> reference beside the relevant plan or subsection in the originating doc. If several docs describe the same item, add the backlink to each relevant live doc.
7. Preserve all original documentation. Do not delete, move, or replace design text with an issue link.
8. Commit and push the doc-backlink changes as one coherent documentation-only batch, following the repository's normal contribution rules.
9. Comment on this control issue with:
   • issues created or reused;
   • docs linked;
   • stale/completed candidates skipped and why;
   • the next source file or section to inspect.

If a candidate cannot be scoped confidently, do not create a speculative issue. Report it in the nightly comment for human review.

Child issue template

Summary

A concise description of the observable outcome.

Source documentation

• Link to the exact repository document and relevant heading.
• List any other docs that describe the same work.

Current state

What exists today, including relevant code/tests, and what is still missing.

Scope

What this issue includes and explicitly does not include.

Acceptance criteria

• Concrete behavior or design decision is complete.
• Focused tests or design artifacts are added/updated.
• docs/design.md and docs/architecture.md are updated when the language, namespace, stdlib-loading, or compiler policy changes.
• The originating planning docs remain in place and reflect the issue's final status.

Dependencies / open questions

Related issues, ordering constraints, or decisions that must be made first. Omit this section when none exist.

Migration checklist

• docs/active/ audited and linked
• docs/open_design/ audited and linked
• docs/progress.md Partial/Not started entries audited and linked
• docs/design.md and docs/architecture.md explicit future work audited and linked
• Final duplicate/staleness pass completed
• Every live issue created by this migration links to its source docs
• Every originating live doc links back to its issue(s)

Definition of done

• Each confirmed outstanding documented work item has exactly one primary GitHub issue (or a clearly linked parent/sub-issue structure).
• Issue bodies link to the source documentation, and live source docs link back to the issues.
• Completed, duplicated, and obsolete notes were not turned into misleading open work.
• No documentation was removed merely because an issue now exists.
• This control issue contains an auditable nightly batch log.

[vycdev2]

Nightly batch:

• Created design: define module imports and trusted stdlib origins #3, design: define module imports and trusted stdlib origins, after confirming the current interpreter-only trust marker, lexical stdlib loading, and lack of a real module/import registry.
• Linked docs/active/stdlib_visibility_design.md (Recommendation) and docs/active/stdlib_json_extraction_plan.md (Public json.* Handoff) back to design: define module imports and trusted stdlib origins #3 in documentation PR docs: link outstanding design issues #4.
• Did not create a separate issue from json_value_transition_plan.md: its implementation stages are recorded as complete, while the remaining root-alias/public-spelling decision overlaps the prelude policy explicitly included in design: define module imports and trusted stdlib origins #3.
• Did not inspect docs/completed/ candidates because the ordered docs/active/ audit is not complete.
• Next source to inspect in depth: docs/active/canonical_reflection_metadata_plan.md, especially whether its Stage 5 / recommended-next-bite text contains a bounded outcome beyond ongoing metadata-insertion auditing.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Reused the open documentation PR docs: link outstanding design issues #4 and kept this run to one new work issue.
• Audited docs/active/canonical_reflection_metadata_plan.md. Did not create an issue: its finite migration stages and fallback audit are implemented, while the listed follow-ups are ongoing invariants for future metadata operations rather than an independently completable unit.
• Created design: define long-term raw JSON lookup guidance #5, design: define long-term raw JSON lookup guidance, after confirming that the strict/lenient helper split and its tests are implemented but the durable naming, usage, and compatibility guidance remains undecided.
• Linked docs/open_design/json_raw_access_semantics.md (Decision) and docs/active/stdlib_json_extraction_plan.md (Open Questions) back to design: define long-term raw JSON lookup guidance #5 in PR docs: link outstanding design issues #4.
• Next source to inspect in depth: docs/open_design/json_unknown_field_policy.md, checking whether any configurability question remains beyond the implemented json.parse_exact path.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Created or reused no child issues in this run.
• Audited docs/open_design/json_unknown_field_policy.md against the current stdlib bridge, documentation, and focused fixtures. Did not create an issue: its recommended staged outcome is implemented—json.parse[T] remains lenient and json.parse_exact[T] recursively rejects unknown fields for closed reflected shapes. The note only presents per-type or per-field configurability as a possible later extension, without a decided requirement or independently completable scope, so tracking it now would be speculative.
• Audited docs/open_design/math_numeric_overload_boundary.md against the typechecker/interpreter paths and focused fixtures. Did not create an issue: the document marks the current boundary decided, and the exact int64/float64 signatures, mixed-type rejection, and secret lifting are implemented. Broader overload or numeric-constraint work is explicitly deferred until a general model exists.
• Duplicate search found no separate open or closed issue/PR for parse_exact, unknown-field configurability, or the math numeric overload boundary. No documentation backlinks were added, so documentation PR docs: link outstanding design issues #4 remains unchanged and waiting for review.
• Verification passed: cargo test -q -p jett_driver run_pass_json_unknown_fields, cargo test -q -p jett_driver run_pass_json_parse_exact, cargo test -q -p jett_driver math_numeric_builtin, cargo test -q -p jett_driver run_pass_math_operations, and cargo test -q -p jett_driver run_pass_math_advanced.
• Next source to inspect in depth: docs/open_design/state_machine_type_model.md, confirming which type-model questions remain unresolved versus implemented state-machine reflection and JSON behavior.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Created or reused no child issues in this run.
• Audited docs/open_design/state_machine_type_model.md and its linked docs/open_design/state_machine_json_contract.md against the checked type model, branch-fact implementation, design/architecture text, and state-machine fixtures. Did not create an issue: the finite type model, namespace support, exact single-state narrowing, reflection, and JSON envelope are implemented; the remaining questions (multi-state/path facts, API state erasure, JSON migration annotations, and generated transition helpers) are explicitly future policy choices without a decided requirement or independently completable scope.
• Duplicate searches found no separate open or closed issue/PR for state-machine narrowing, state renames, machine JSON migration, or transition effects beyond this control issue. No documentation backlinks were added, so documentation PR docs: link outstanding design issues #4 remains unchanged and waiting for review.
• Verification passed: cargo test -q -p jett_driver state_machine (34 matching fixture tests), cargo fmt --check, cargo build, cargo test -q, and git diff --check.
• Next source to inspect in depth: docs/open_design/namespace_qualified_types_followup.md, checking whether its remaining import/prelude and bootstrap compatibility boundary is already covered by design: define module imports and trusted stdlib origins #3 or contains a separate bounded outcome.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Reused design: define module imports and trusted stdlib origins #3, design: define module imports and trusted stdlib origins; created no new child issue.
• Audited docs/open_design/namespace_qualified_types_followup.md and the directly related docs/open_design/prelude_root_aliases.md. Canonical qualified symbols, local namespace aliases, duplicate-leaf declarations, reflection, JSON, interfaces, actors, and state machines are implemented and covered. The remaining import/prelude, root-shorthand, bootstrap, and trusted-origin questions overlap design: define module imports and trusted stdlib origins #3 rather than forming a separate bounded issue.
• Added both open-design notes to design: define module imports and trusted stdlib origins #3’s source-documentation list and linked both notes back to design: define module imports and trusted stdlib origins #3 in documentation PR docs: link outstanding design issues #4 (commit f9e924b).
• Verification passed: cargo test -q -p jett_driver run_pass_namespace (14 fixture tests), cargo test -q -p jett_driver compile_fail_namespace (22 fixture tests), cargo fmt --check, cargo build, cargo test -q, and git diff --check.
• Next source to inspect in depth: docs/open_design/reflection_predicate_facts.md, checking whether its remaining predicate-fact work is implemented, speculative, or independently completable.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Created design: define reflection predicate facts for generic specialization #6, design: define reflection predicate facts for generic specialization, after confirming the checker implements direct reflection comparisons, immutable reflection-value facts, helper parameters, and matches while deliberately rejecting predicate-call and copied-boolean generic cast guards.
• Linked docs/open_design/reflection_predicate_facts.md (Possible Directions) back to design: define reflection predicate facts for generic specialization #6 in documentation PR docs: track reflection predicate facts design #7.
• Duplicate searches found no separate open or closed issue/PR for reflection predicates, TypePrimitive predicates, or generic-specialization predicates beyond this control issue.
• Verification passed: cargo test -q -p jett_driver generic_reflection_predicate_fact_boundary, cargo test -q -p jett_driver generic_reflection_boolean_fact_boundary, cargo fmt --check, cargo build, cargo test -q, and git diff --check.
• Next source to inspect in depth: docs/open_design/print_debug_builtin_policy.md, checking whether its builtin-to-stdlib migration boundary is still outstanding, already tracked, or dependent on design: define module imports and trusted stdlib origins #3.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Created design: define stable print and println capability policy #8, design: define stable print and println capability policy, after confirming that global printing remains capability-free and secret-blocked in the checker, writes through interpreter stdout, and has no decided release/native lowering policy.
• Linked docs/open_design/print_debug_builtin_policy.md (Recommendation) back to design: define stable print and println capability policy #8 in documentation PR docs: link print debug policy issue #9.
• Duplicate searches found no separate open or closed issue/PR for print / println, capability-free output, or the Stdout capability policy beyond this control issue.
• Verification passed: cargo test -q -p jett_driver run_pass_hello_print, cargo test -q -p jett_driver secret_print, cargo test -q -p jett_driver secret_stdout, cargo test -q -p jett_driver run_pass_stdlib_loading, cargo test -q -p jett_driver run_pass_trace_basic, cargo test -q -p jett_driver run_pass_breakpoint_basic, cargo fmt --check, cargo build, cargo test -q, and git diff --check.
• Next source to inspect in depth: docs/open_design/uint64_runtime_value_model.md, checking which runtime-carrier and future-backend boundaries remain independently completable versus already implemented.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Created bug: enforce runtime bounds for sized integer expressions #10, bug: enforce runtime bounds for sized integer expressions, after confirming that literal checks know the smaller integer ranges but the current interpreter only performs range-aware runtime normalization for uint64; a checked uint8 variable expression can currently compute and print 256 from 255 + 1.
• Linked docs/open_design/uint64_runtime_value_model.md (Recommendation) back to bug: enforce runtime bounds for sized integer expressions #10 in documentation PR docs: link sized integer runtime bounds issue #11.
• Did not create a separate future-backend carrier issue: HIR, MIR, and native codegen are not started, and preserving checked expression facts in those backends is not yet independently completable from the broader Phase D work.
• Duplicate searches found no separate open or closed issue/PR for uint64, uint8, fixed-width runtime bounds, or integer overflow beyond the migration control issue.
• Verification passed: cargo test -q -p jett_driver uint64 (4 matching fixture tests), cargo test -q -p jett_comptime uint64 (14 matching unit tests), cargo fmt --check, cargo build, cargo test -q, and git diff --check.
• Next source to inspect in depth: docs/open_design/json_trusted_hooks_across_backends.md, checking whether its future lowering boundary forms a bounded outcome or remains coupled to the not-started backend phases.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Reused design: define module imports and trusted stdlib origins #3, design: define module imports and trusted stdlib origins; created no new child issue.
• Audited docs/open_design/json_trusted_hooks_across_backends.md against the shared jett_common::json bridge table, interpreter trusted-hook checks, related stdlib extraction plan, and Phase D status. The interpreter/typechecker boundary is implemented; bytecode/HIR/MIR/native lowering is not started, and the remaining trusted-origin/import questions are already in design: define module imports and trusted stdlib origins #3, so a separate backend issue would be premature and duplicative.
• Added the note to design: define module imports and trusted stdlib origins #3’s source-documentation list and linked the note back to design: define module imports and trusted stdlib origins #3 in documentation PR docs: link JSON trusted backend design issue #12.
• Duplicate searches found no separate open or closed issue/PR for JSON trusted hooks or backend lowering beyond Mirror outstanding documented work into GitHub issues #2 and design: define module imports and trusted stdlib origins #3.
• Verification passed: cargo test -q -p jett_comptime trusted_json, cargo test -q -p jett_common public_bridge_specs_pin_trusted_hooks, cargo fmt --check, cargo build, cargo test -q, and git diff --check.
• Next source to inspect in depth: docs/open_design/json_value_primitive_tag_retirement.md, confirming whether the note is now stale/completed after removal of the compiler-owned primitive and bootstrap fallback.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Created or reused no child issues in this run.
• Audited docs/open_design/json_value_primitive_tag_retirement.md against the type interner, named-type resolution, bundled JSON declarations, reflection behavior, and focused fixtures. Did not create an issue: the primitive retirement is complete—there is no Type::JsonValue, TypeInterner::JSON_VALUE, TypePrimitive.json_value_type, or no-stdlib typechecker fallback; bundled code gets bare JsonValue only through the stdlib root alias to json.JsonTree.
• The resolver still recognizes the JsonValue spelling while resolving type expressions, but this is compatibility bookkeeping for the source alias rather than a primitive type or reflection tag; the typechecker rejects it when the alias is absent.
• The remaining public-spelling and root-alias questions overlap existing design: define module imports and trusted stdlib origins #3, while raw JSON naming and usage guidance is tracked by design: define long-term raw JSON lookup guidance #5. Duplicate searches found no separate issue or PR for primitive/fallback retirement.
• Verification passed: cargo test -q -p jett_typecheck json_value (2 tests), cargo test -q -p jett_comptime direct_json_value_reflection (2 tests), cargo test -q -p jett_driver json_value_reflection (2 fixture tests), cargo fmt --check, cargo build, cargo test -q, and git diff --check.
• Next source to inspect in depth: docs/open_design/bundle_ordering_contract.md, confirming whether dependency-aware whole-file ordering and agent-readable bundle manifests form one bounded implementation issue or should be split.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

[vycdev2]

Nightly batch:

• Created enhancement: add dependency-aware whole-file bundle ordering #13, enhancement: add dependency-aware whole-file bundle ordering, after confirming that lexical concatenation makes the valid tests/multifile project fail bundle validation with E0205 forward-reference diagnostics.
• Linked docs/open_design/bundle_ordering_contract.md (Future Direction) back to enhancement: add dependency-aware whole-file bundle ordering #13 in documentation PR docs: link bundle ordering issue #14.
• Did not create a separate manifest issue: successful --agent output already emits deterministic source-file line ranges, so enhancement: add dependency-aware whole-file bundle ordering #13 keeps manifest correctness tied to any reordered output. The currently flattened failure diagnostics are also included in enhancement: add dependency-aware whole-file bundle ordering #13 because they are coupled to reporting impossible cycles/interleaving.
• design: define module imports and trusted stdlib origins #3 overlaps the future canonical module dependency model but does not track whole-file bundle ordering; enhancement: add dependency-aware whole-file bundle ordering #13 records that coordination explicitly. Duplicate searches found no other issue or PR for dependency-aware bundling beyond control issue Mirror outstanding documented work into GitHub issues #2 and merged test PR test: preserve bundle output on validation failure #1.
• Verification passed: cargo test -q -p jett_driver bundle_project, cargo test -q -p jett_cli bundle_agent_output_lists_bundled_files, cargo fmt --check, cargo build, cargo test -q, and git diff --check. A direct jett bundle tests/multifile --agent reproduction exited 1 with eight E0205 diagnostics and did not create the output file.
• Next source to inspect in depth: docs/open_design/type_construction_block_syntax.md, together with docs/open_design/type_construction_design.md, checking whether the deferred construction syntax is independently actionable or still blocked on general block-expression design.

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.