Skip to content

Make source comments accurately describe execution and ownership #909

Closed

Description

@taras

Contributors should be able to use source comments and architecture prose to understand current execution, ownership and replay behavior. For example, the plan workflow introduction currently says it has no Files capability even though ordinary reads are available; generated-expression documentation describes trusted JavaScript even though generated props use a restricted data interpreter.

A follow-up review of nine earlier architect, planner and implementor conversations found that the cleanup in #908 preserved useful rationale, but left several stale descriptions and specific original requests unresolved. This is a bounded correction of those passages.

Contract

  • Describe plan workflow reads separately from refused mutations, and describe PI27 as a joined-teardown test rather than a retired grant test.
  • Attribute the <Dir> implementation to canonical core, distinguish host admission identities, and describe the Evaluate recorder as contextual Files middleware.
  • Describe unknown declaration-kind rejection at capture, and include structural declarations in inspection and validation props documentation.
  • Distinguish private scope in a component body from caller scope restored by projected content, consistently in source and architecture.
  • Distinguish ordinary JavaScript expression props from generated data expressions.
  • Describe repeated identity statements through the same installation, and explain weak-key provenance without promising exact garbage-collection timing.
  • Identify firstUnaligned() as the production terminal replay check, separately from the older unconsumed-yield predicate.
  • Explain fresh append-owned rejection records and sharing across loaded copies through the stable Context name. Keep this distinct from module-local journal provenance.
  • Consolidate the specifically reviewed identity/request repetition, remove the repeated inline gate-copy explanation, move the pipe-cancellation rationale beside its teardown test, and clarify build manifest validation before sequential writes. Preserve consequential constraints and fix the whole- fragment spacing.

Acceptance and evidence

Each rewritten explanation agrees with its current implementation and consumers. Retain the reasons behind cancellation, synchronous request closure, check/use protection, identity stability, replay validation and gate/backend sequencing.

The patch contains only the named source-comment changes and the matching declaration-capture and private-closure paragraphs in architecture.md. Runtime statements, types, signatures, identifiers, strings, fixtures, tooling directives, dependency state and generated files remain identical. The banned-word list and agent guidance keep their current scope.

Compare non-comment TypeScript tokens, emitted JavaScript with comments removed, and protected tooling/license/provenance annotations against main. Verify the architecture diff is confined to the intended paragraph and preserves literal code. Run git diff --check, targeted Oxlint and formatter checks, and the architecture prose check after normal deno task setup preparation. No new behavioral tests or full runtime corpus are needed for this comment-only correction.

Deliver one reviewable PR against main with a finding-to-change record and exact verification results. This issue remains open until merge. Additional repository-wide pruning and expansion of the banned-word list are outside this work.

Activity

  1. added
    documentationImprovements or additions to documentation
    cleanupAuto-generated cleanup finding from repo analysis
    on Oct 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    cleanupAuto-generated cleanup finding from repo analysisdocumentationImprovements or additions to documentation

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions