[cixzhang]

Exact decision needed

Where a native component's views live in its language's implementation, when core keeps that component inside another component's folder. AST-093 FR1 says each native component has its own folder "named as the core component" (Sources/Astryx/<Name>/), but core keeps AvatarStatusDot in Avatar/, and the Swift AvatarStatusDot views already sit in Sources/Astryx/Avatar/ beside Avatar's. An earlier owner decision approved that placement; FR1 does not yet say it.

Existing authority searched

• spec:AST-093 FR1 (this record): names the views' folder by <Name>.
• architecture:knowledge-contracts DEC-15: a component's records live in docs/specs/components/<ComponentRoot>/, mirroring the component's source tree, where <ComponentRoot> is the core source directory.
• Code: packages/native/apple/Sources/Astryx/Avatar/ holds both Avatar and AvatarStatusDot.
• Open work: none edits FR1. docs(native): every Swift shared rule is an architecture record #8500 edits a different section of this record (Current state) and the native READMEs.

Decision

A native component's views live in the folder that mirrors its core component root, the core source directory: <ComponentRoot>, which is <Name> when core keeps the component in its own folder. Core's Avatar/AvatarStatusDot puts the Swift AvatarStatusDot views in Avatar/. For Swift the views are in packages/native/apple/Sources/Astryx/<ComponentRoot>/. This is the same placement rule DEC-15 sets for records. The folder is part of the contract because spec lookup (pnpm specs:for) routes a native view to its component's records by it (architecture:knowledge-contracts INV18).

Rejected alternatives

• One folder per public name (Sources/Astryx/AvatarStatusDot/): splits a family core keeps together and differs from where its records live.

Claim scope and non-goals

• Only the folder of a native component's views. File names, the spec's location, ids, and platform_of are unchanged.
• FR1's verification row adds the member case and the failure for views outside the mirrored folder.
• The native package READMEs that still describe a <Name>/ folder are aligned in a separate docs follow-up.

Evidence and implementation relationship

• The Swift package already matches: AvatarStatusDot's views are in Sources/Astryx/Avatar/. No code changes.

Writing rubric results

• R1 narration: none; the added sentence is present tense about the system.
• R2 research in the record: none.
• R3 evidence naming a change: none.
• R4 rejected alternatives over one line or outside a decision: none added to the record.
• R5 pull request or issue references remaining: none.
• R6 ruled open questions still listing options: none.

Scope

• This PR contains specification records only.
• It records observable behavior and preserves equivalent internal implementations.
• Any named internal mechanism is intentionally public, names its dependent caller/system, and explains why an equivalent implementation would not satisfy the contract.
• Verification states the evidence layer and failure signal without prescribing CI job/workflow topology.
• It records one intentional durable decision, not a rescue for a separable tagalong.
• The canonical knowledge owner, affected current claims, and overlapping open work are named; any ownership collision is resolved or called out for human decision.
• Adjacent API, visual, accessibility, composition, and implementation facts remain outside scope unless this exact decision depends on them.
• Public text and artifacts contain no internal Meta context.

Validation

• pnpm check:knowledge
• Prettier
• git diff --check

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Nov 1, 2026 6:50pm UTC

[astracat-bot]

AI review status for this pull request.

Review status	Updated
❓ Needs maintainer input (for maintainers only)	Nov 1, 2026, 7:03 PM UTC

[astracat-bot]

Approval waits on an engineering owner's decision on the amended spec:AST-093 FR1, which moves a native component's views from a folder named <Name> to the folder that mirrors its core component root, and on its new verification row. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner. Separately, architecture:knowledge-contracts INV18 asks an amended requirement that names a source folder to show why that layout is a contract, and FR1 does not yet: one clause saying that spec lookup routes a Swift view to its records by that folder, or moving the rule to an architecture record, would resolve it. The Swift package and native specs READMEs still describe <Name>/ folders and can be updated here or in a follow-up.

[Automated review]

[astracat-bot]

This amended clause names a source folder (Sources/Astryx/<ComponentRoot>/), which architecture:knowledge-contracts INV18 allows in a system spec only when the record shows the layout is an intentional public contract. One clause naming what depends on it would do that: spec lookup routes a Swift view to its records by its component-root folder. Alternatively, move the folder rule to an architecture record.

[astracat-bot]

Approval waits on an engineering owner's decision on the amended spec:AST-093 FR1, which moves a native component's views from a folder named <Name> to the folder that mirrors its core component root, and on its new verification row. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner. The new clause naming spec lookup as the reason the folder is part of the contract resolves the earlier architecture:knowledge-contracts INV18 concern, and no other change is required. Two optional follow-ups: FR1 could say that a member's view reaches its own records only when the file carries the member's name, and the Swift package and native specs READMEs still describe <Name>/ folders.

[Automated review]