Mirror outstanding documented work into GitHub issues

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.

Start by auditing docs/active/.md, then docs/open_design/.md, docs/progress.md, docs/design.md, and docs/architecture.md in the stated order. Inspect current code and tests, search existing issues, and create at most three independently completable issues per run while adding reciprocal documentation backlinks. Done means every confirmed outstanding item has one tracked issue, duplicates and stale work are skipped, and this control issue has an auditable batch log.