# Asher Wolfstein Meta Code Style

**[META]**

**Version:** Draft — v0.0.4

**License:**  CC BY-NC-ND https://creativecommons.org/licenses/by-nc-nd/4.0/

## 1. Scope And Conformance [META-SCOPE]

### 1.1. Normative Language [META-NORM]

**[META-NORM-01]** The terms **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, and **MAY** indicate rule strength:

- **MUST** and **MUST NOT** identify _requirements._
- **SHOULD** and **SHOULD NOT** identify strong _defaults_ that may be departed from when grammar, correctness, or clarity requires it.
- **MAY** identifies an _optional_ form.

**[META-NORM-02]** Every normative rule **MUST** have a stable _identifier._ An identifier **MUST** define its requirement in exactly _1 location;_ other rules **SHOULD** refer to that identifier instead of restating it.

**[META-NORM-03]** Unidentified prose, diagrams, and worked examples are _nonnormative._ If an example disagrees with an identified rule, the identified rule controls.

**[META-NORM-04]** Grammar, type correctness, runtime behavior, evaluation order, name resolution, source compatibility, and required tooling **MUST** take priority over formatting. _Formatting_ **_MUST NOT_** _alter any of them._

**[META-NORM-05]** A _construct-specific_ rule explicitly identified as an exception **MUST** override a general rule. _Otherwise, the general rule applies._

**[META-NORM-06]** Existing source **SHOULD** be consulted only when a profile remains _incomplete._ A repeated local pattern **SHOULD** be preferred to a one-off example, _but existing source_ **_MUST NOT_** _override an explicit rule._

**[META-NORM-07]** A language specification, reference implementation, or target compiler **MUST** be the authority for syntax and semantics. Community conventions and formatter behavior **SHOULD** inform the profile _but_ **_MUST NOT_** _be mistaken for intrinsic rules of the language._

### 1.2. Purpose

This document defines a method for producing a coherent style guide for a programming language. It is not a direct formatting standard for source code. A language-specific guide, called a **_language profile_**, instantiates its concepts using the _grammar, semantics, tooling,_ and _conventions_ of a particular language and version.

The given methodology uses _whitespace, indentation, delimiter placement,_ and _vertical alignment_ especially to expose _source structure_ and _evaluation order._ Compact syntax is preferred for language-specific statements and expressions, such as _variable assignment._ Expanded syntax is preferred when it reveals relationships among _operands, declarations, list items, branches,_ and other structural units.

**[META-SCOPE-01]** A language profile based on this guide **MUST** identify:

- its language, dialect, and supported versions;
- the source and file kinds to which it applies;
- vendored, generated, embedded, or tool-controlled source that it excludes; and
- any formatter, compiler, parser, or linter that controls part of its output.

**[META-SCOPE-02]** This meta-guide **MUST NOT** be treated as part of a language profile itself. A language profile **MUST** first map a meta-rule to syntax supported by its target language in order for a rule to apply.

**[META-SCOPE-03]** Examples in either this guide or a derived profile **MUST NOT** be treated as rules for concerns outside their stated scope.

### 1.3. Priorities [META-PRIORITY]

**[META-PRIORITY-01]** A language profile **SHOULD** prioritize, in order:

1. Correctness and supported syntax.
2. Visible structure and evaluation order.
3. Clear control flow and ownership.
4. Consistency within the surrounding logical unit.
5. Compatibility with required tools.
6. Compactness.

**[META-PRIORITY-02]** Formatting **SHOULD** make related tokens appear related. _It_ **_MUST NOT_** _imply a scope, dependency, grouping, or execution order that the program does not have._

**[META-PRIORITY-03]** A profile **SHOULD** prefer a small set of composable general rules as opposed to repeated construct-specific prescriptions. _A special rule_ **_SHOULD_** _exist only when the target language or clarification requires it._

### 1.4. Core Rules And Portable Defaults [META-PORT]

Rules about correctness, rule ownership, explicit exceptions, and validation are _core requirements_ for every profile.

**[META-PORT-01]** _Whitespace counts, line length, delimiter placement, operator position, and break thresholds are portable defaults that a profile_ **_MAY_** _adapt._

**[META-PORT-02]** A profile **MUST** adopt each applicable core requirement. It **MUST** replace an inapplicable portable default with an explicit language-specific decision _rather than remaining incomplete or ambiguous._

**[META-PORT-03]** An adaptation **MUST** state the language fact that requires it, the replacement behavior, and the constructs affected. _An adaptation_ **_MUST NOT_** _be broader than that reason requires._

## 2. Source And Layout Model

### 2.1. Source Units [META-TOKEN]

This guide distinguishes grammatical structure from the units used for visual layout.

- A **_lexical token_** is a _token_ as recognized by the target language.
- A **_style token_** is a source unit treated as 1 item for spacing or alignment.
- A **_protected source unit_** is text whose internal characters cannot be reformatted independently.
- A **_composite operand_** contains internal structure but behaves as 1 operand in its enclosing context.
- A **_construct_** is a language-specific grammatical unit such as an _expression, declaration, list, block,_ or _directive._

**[META-TOKEN-01]** A profile **MUST** inventory its **_style tokens_** and **_protected source units._** The inventory **MUST** include, when applicable, _identifiers, keywords, literals, comments, operators, delimiters, separators, annotations, directives, interpolation forms,_ and empty delimiter pairs.

**[META-TOKEN-02]** A multi-character token or grammar-required adjacency **MUST** remain indivisible. _Characters_ **_MUST NOT_** _be separated when doing so would change tokenization, parsing, meaning, or tool interpretation._

**[META-TOKEN-03]** A _string, comment, regular expression, heredoc-like form, embedded language, generated fragment,_ or other _protected source unit_ **MUST NOT** be internally reformatted _unless a dedicated rule governs that unit’s own language either within the profile or within that language’s own profile._

**[META-TOKEN-04]** A token with context-dependent roles **MUST** be classified by grammatical use. The same spelling may require different layouts depending on whether it is a _unary operator, binary operator, separator, annotation marker, type constructor,_ or _delimiter._

**[META-TOKEN-05]** A _composite operand_ **MUST** establish and retain its own _local layout context._ Operators within it **MUST** be aligned and counted according to that local context, but **MUST NOT** participate in alignment or operator counting in any containing context.

### 2.2. Layout Terms [META-LAYOUT]

- A **_structural base_** is the column at which a _statement, declaration, expression,_ or _block_ begins.
- An **_operator base_** is the column occupied by the controlling operator or relation in a multiline construct.
- An **_operand column_** is the column at which operands of that controlling relation begin.
- An **_alignment base_** is the first column shared by equivalent items.
- A **_local context_** is a bounded region whose internal alignment is independent of its container.
- An **_alignment group_** is a contiguous set of related items whose comparable tokens shall align with one another.
- A **_continuation_** is a physical line that continues a grammatical unit begun earlier.

**[META-LAYOUT-01]** Every multiline construct **MUST** have an identifiable **_structural base._** Every nested multiline construct **MUST** derive its base from the grammatical position it occupies rather than from an unrelated fixed **_continuation_** width.

**[META-LAYOUT-02]** Structural indentation **MUST** identify scope or containment. Alignment spaces **MUST** identify relationships within that structure and **MUST NOT** create the appearance of another scope.

**[META-LAYOUT-03]** A _local context_ **MUST** own its internal breaks, indentation, and alignment. Tokens inside it **MUST NOT** be pulled outward merely to align with tokens in a containing or neighboring context.

## 3. Language Profile Foundation [META-PROFILE]

### 3.1. Language Facts

**[META-PROFILE-01]** Before deriving layout rules, a profile **MUST** document or cross-reference the language and tooling acts that constrain those rules. For each concern below, it **MUST** identify the applicable mechanism and authority or explicitly mark the concern inapplicable.

|       Concern        | Required Fact Or Reference                                               |
|:--------------------:| ------------------------------------------------------------------------ |
|   Language target    | Language, dialect, edition, and version range                            |
|  Grammar authority   | Specification, parser, compiler, or reference implementation             |
|      Whitespace      | Whether spaces, tabs, indentation, or newlines are significant           |
| Statement boundaries | Explicit terminators, significant newlines, or automatic insertion rules |
|     Continuation     | Where line breaks are legal and whether an escape is required            |
|   Token adjacency    | Tokens or token pairs that must remain joined                            |
|      Operators       | Arity, precedence, associativity, fixity, and evaluation guarantees      |
|      Delimiters      | Legal pairs, ownership, empty forms, and nesting behavior                |
|       Comments       | Line, block, documentation, directive, and trailing forms                |
|       Literals       | Multiline, interpolated, raw, regular-expression, and embedded forms     |
|     Declarations     | Signatures, modifiers, annotations, types, defaults, and bodies          |
|     Control flow     | Branches, loops, pattern matching, handlers, and transfers               |
|   Metaprogramming    | Macros, preprocessors, generated regions, or token trees                 |
|       Tooling        | Required formatter, linter, parser, compiler, and editor constraints     |

**[META-PROFILE-01-TABLE-01]**

**[META-PROFILE-02]** A profile **MUST** distinguish _invalid syntax, syntax that is valid but unsupported by the target version, syntax that is deprecated,_ and _syntax that is merely discouraged by style._

**[META-PROFILE-03]** If a required formatter owns the complete representation, the profile **SHOULD** delegate overlapping physical-layout choices to that formatter. Project rules **SHOULD** then address configuration, naming, organization, and concerns the formatter does not own.

### 3.2. Operators And Relations [META-GRAMMAR]

**[META-GRAMMAR-01]** A profile for a language with _infix, prefix, postfix,_ or _mixfix_ operators **MUST** maintain an operator table containing:

|       Field        | Meaning                                                                  |
|:------------------:| ------------------------------------------------------------------------ |
|      Spelling      | The complete indivisible token or token sequence                         |
|        Role        | Unary, binary, n-ary, separator, binder, or another grammatical role     |
|       Fixity       | Prefix, infix, postfix, circumfix, or mixfix                             |
|     Precedence     | Relative binding strength in the target grammar                          |
|   Associativity    | Left, right, none, or grammar-specific                                   |
|     Evaluation     | Any order, short-circuiting, laziness, sequencing, or undefined behavior |
|   Break legality   | Whether the token may lead or trail a continued line                     |
| Context exceptions | Uses whose role or precedence differs                                    |

**[META-GRAMMAR-01-TABLE-01]**

**[META-GRAMMAR-02]** The profile’s visual hierarchy **MUST** be derived from the _parsed structure,_ not from token spelling alone. _Parentheses, grouping forms, implicit application, pattern syntax,_ and _context-dependent precedence_ **MUST** be respected.

**[META-GRAMMAR-03]** When the language does not use precedence-based expressions, the profile **MUST** identify the equivalent structural relation, such as _syntax-tree nesting, list nesting, dataflow order,_ or _explicit block ownership._

### 3.3. Delimiter Inventory [META-DELIM]

**[META-DELIM-01]** A profile **MUST** maintain a delimiter matrix for _every applicable context:_

- call arguments;
- declaration parameters;
- grouped expression;
- data literal;
- index or slice;
- annotation or attribute;
- block or body; and
- any other language-specific form.

_And for every form:_

- compact form;
- multiline opener;
- multiline closer;
- empty form;
- trailing separator where applicable; and
- any other language-specific placement.

**[META-DELIM-02]** Each nonempty delimiter pair **SHOULD** establish a local context. A profile **MUST** document any delimiter whose contents instead share the containing context.

**[META-DELIM-03]** Opening and closing delimiter placement **MUST** reveal ownership. A closer **MUST NOT** be positioned so that it appears to close a neighboring or outer construct.

**[META-DELIM-04]** Consecutive delimiters **SHOULD** remain visually adjacent when their contexts begin or end together. They **MUST** separate when adjacency would hide distinct ownership or violate the grammar.

### 3.4. Derivation Workflow

**[META-PROFILE-04]** A language profile **SHOULD** be developed in this order:

1. Fix the language, dialect, version range, source scope, and required tools.
2. Record language facts, protected units, operator relations, delimiters, and legal break positions.
3. Adopt each portable default or document its narrow language-specific adaptation under META-PORT-03.
4. Populate the construct inventory and give every distinct behavior 1 owning rule.
5. Add minimal examples, exception records, formatter configuration, and validation fixtures.
6. Run source, rule, compatibility, and idempotence checks before publishing the profile.

## 4. Portable Layout Architecture

### 4.1. Whitespace And Physical Lines [META-SPACE]

**[META-SPACE-01]** Adjacent style tokens **SHOULD** be separated by _visible whitespace_ when the grammar permits and adjacency (lacking whitespace) does not communicate a language-defined relationship. _Required adjacency and protected units_ **_MUST_** _override this default._

**[META-SPACE-02]** A profile **SHOULD** use _2 spaces_ for each structural indentation level. It **MAY** choose another unit when the grammar, an enforced formatter, a fixed-column representation, or a binding project constraint requires one.

**[META-SPACE-03]** Tabs **SHOULD NOT** be used for indentation or alignment. A profile for a language or representation in which tabs are semantic or mandatory **MUST** define their exact role and **MUST NOT** mix that role with visual padding.

**[META-SPACE-04]** Trailing whitespace **MUST NOT** be present unless it is _semantically significant._ When it is significant, _the profile_ **_MUST_** _define a visible validation strategy that protects it from accidental removal._

**[META-SPACE-05]** A profile **SHOULD** use _120 columns as its default soft line limit._ It **MAY** choose another limit for ecosystem, display, or tool compatibility. An indivisible source unit **MAY** exceed the limit when breaking it would be illegal or less clear.

**[META-SPACE-06]** Additional spaces **MAY** align comparable tokens inside 1 alignment group. Alignment **MUST NOT** cross an unrelated _statement, declaration, container, branch, handler, scope,_ or _blank-line_ boundary.

**[META-SPACE-07]** Blank lines **MAY** separate _conceptual_ or _alignment groups._ A blank line **MUST NOT** imply a _grammatical grouping, scope,_ or _execution boundary_ that the language does not provide.

**[META-SPACE-08]** A line break **MUST NOT** be introduced where the language treats _a newline as termination, changes automatic terminator insertion, alters indentation semantics, changes a preprocessor directive,_ or otherwise affects parsing.

### 4.2. Hierarchy And Alignment [META-ALIGN]

**[META-ALIGN-01]** _Multiline layout_ **_MUST_** _mirror the construct’s syntax tree or equivalent structural hierarchy._ An outer controlling relation **MUST** appear no farther right than a relation nested inside one of its operands.

**[META-ALIGN-02]** When _leading-operator continuation_ is legal, a construct’s controlling operator token_—or the aligned tokens of a single mixfix operator—_**SHOULD** occupy the construct’s _operator base._ Its peer operands **SHOULD** begin in a common operand column, _normally 1 space after the widest controlling token._ When the construct is nested as an operand, its operator base **SHOULD** begin at the containing context’s _operand column._

**[META-ALIGN-03]** Equivalent operators or separators at the same grammatical level **SHOULD** align vertically. Operators **MUST NOT** align when doing so would imply an associativity or grouping _different from the parsed program._

**[META-ALIGN-04]** When _leading operators_ are _illegal, unsafe,_ or _strongly misleading_ in the target language, the profile **MUST** define a _trailing-operator_ or _enclosing-delimiter_ alternative that preserves the same visible hierarchy.

**[META-ALIGN-05]** Formatting **MUST** preserve _associativity, short-circuit boundaries, sequence points, lazy evaluation, exception boundaries,_ and other _evaluation constraints._ Explicit grouping **SHOULD** be added when layout alone cannot make the intended grouping clear, and the grouping does not alter behavior.

**[META-ALIGN-06]** When _hierarchy-based alignment_ would exceed the line limit or create excessive space, a clearer accommodating indentation **SHOULD** replace it. _The fallback_ **_SHOULD_** _be the smallest regular indentation that preserves ownership._

### 4.3. Break Decisions [META-BREAK]

**[META-BREAK-01]** A profile **MUST** define _deterministic conditions_ under which each _expression, list, declaration, header,_ and _body_ remains _compact_ or becomes _multiline._

**[META-BREAK-02]** The following portable defaults **SHOULD** be used, but **MUST NOT** violate the target grammar:

- an assignment used as a complete statement **MUST** become multiline;
- a context with no assignment and no more than 1 structural operator **MAY** remain compact;
- a context with 2 or more structural operators **MUST** become multiline;
- a list with 1 or 2 simple items **MAY** remain compact;
- a list with 3 or more items **MUST** become multiline; and
- when a breakable construct exceeds the line limit, the _innermost local context_ that can legally reflow the overflowing item **MUST** become multiline; the break **MUST** propagate outward only as required by `META-BREAK-04`.

**[META-BREAK-03]** Operator counts and complexity thresholds **MUST** be calculated separately for each l_ocal context._ Content inside a nested context or _composite operand_ **MUST NOT** cause an unrelated outer context to cross its threshold.

**[META-BREAK-04]** When a child construct becomes multiline, the profile **MUST** define whether and how that break propagates to its parent. _Break propagation_ **_MUST_** _preserve delimiter ownership and_ **_MUST NOT_** _flatten the child’s local alignment into the parent._

**[META-BREAK-05]** Once a context is multiline, equivalent continuation tokens **SHOULD** use a consistent leading or trailing position as defined by the language profile.

**[META-BREAK-06]** A _protected source unit_ **MUST NOT** be broken merely to satisfy a stylistic threshold. _The containing construct_ **_SHOULD_** _use an accommodating layout instead._

**[META-BREAK-07]** Formatting decisions **SHOULD** be stable: _adding or removing an unrelated line_ **_SHOULD NOT_** _reflow distant alignment groups, and formatting already conforming source_ **_MUST_** _be idempotent._

### 4.4. Lists And Repeated Items [META-LIST]

**[META-LIST-01]** A profile **MUST** distinguish grammatical list _kinds,_ including _arguments, parameters, generic or type arguments, data entries, inheritance lists, import lists, pattern alternatives,_ and _language-specific lists._ Rules for 1 list kind **MUST NOT** be assumed to govern another.

**[META-LIST-02]** When legal, a multiline _expression-item list_ **SHOULD** keep its opening delimiter _with the first item,_ align each later item with the first item’s _alignment base,_ and keep its closing delimiter with the final item. _A profile_ **_MUST_** _define exceptions for signatures, headers, or conventional hanging-delimiter forms._

**[META-LIST-03]** A multiline declaration _parameter list_ **SHOULD** place the opener _at the end of the declaration head, place each parameter on its own line,_ and place the closer _at the declaration’s structural base_ when a body follows. _A language profile_ **_MUST_** _adapt this default when its grammar or formatter requires another form._

**[META-LIST-04]** The profile **MUST** decide _trailing-separator_ behavior independently for each list _kind._ The decision **MUST** account for _grammar support, diff stability, delimiter placement, variadic markers,_ and _formatter_ behavior.

**[META-LIST-05]** The complexity of each top-level item **MUST** be assessed within that item. A complex item **MAY** expand the containing list, _but operators inside a deeper nested context_ **_MUST NOT_** _be counted as siblings of the item._

**[META-LIST-06]** _Prefix markers, default separators, key/value separators,_ and comparable _suffixes_ **MAY** form _local alignment columns._ _A long item_ **_MAY_** _begin a new group so that it does not impose excessive padding on shorter items._

## 5. Construct Profile

### 5.1. Construct Inventory [META-CONSTRUCT]

**[META-CONSTRUCT-01]** A language profile **MUST** classify every in-scope construct that has distinct layout behavior. Each entry **MUST** record:

|       Field       | Required Content                                                     |
|:-----------------:| -------------------------------------------------------------------- |
|     Construct     | The language’s name for the grammatical form                         |
|   Grammar node    | The specification or parser category that owns it                    |
|    Outer role     | Atomic unit, operand, declaration, statement, body, or directive     |
| Internal contexts | Expressions, lists, signatures, captures, patterns, types, or bodies |
| Compact condition | When the complete form may remain on 1 line                          |
|  Break triggers   | Count, complexity, comments, line limit, or mandatory grammar        |
|  Multiline bases  | Structural, operator, operand, and item alignment columns            |
|    Delimiters     | Opener, closer, empty form, and ownership                            |
|    Separators     | Position, alignment, and trailing behavior                           |
|     Ordering      | Modifier, clause, branch, member, or evaluation order constraints    |
|    Exceptions     | Explicit references to overridden general rules                      |
|    Validation     | Parser, compiler, linter, formatter, or fixture coverage             |

**[META-CONSTRUCT-02]** The inventory **MUST** cover each applicable family below and mark an inapplicable family explicitly:

- names, qualification, member access, optional access, and chaining;
- indexing, slicing, dereferencing, and postfix operations;
- calls, construction, argument lists, and named arguments;
- functions, methods, parameters, return declarations, and defaults;
- closures, lambdas, callable references, captures, and generators;
- literals, collections, mappings, records, tuples, and destructuring;
- unary, binary, n-ary, conditional, pipeline, and assignment expressions;
- annotations, attributes, decorators, modifiers, and visibility;
- types, generic constraints, unions, intersections, and nullability;
- classes, interfaces, traits, protocols, enums, modules, and namespaces;
- conditionals, loops, switches, matches, handlers, and control transfers;
- imports, includes, directives, pragmas, macros, and preprocessing; and
- comments, documentation, embedded languages, and generated regions.

### 5.2. Reusable Construct Principles

#### 5.2.1 (Fluent-)Chains [META-CHAIN]

**[META-CHAIN-01]** A _member, selector, path,_ or _fluent-chain_ step **SHOULD** remain part of its subject’s _composite operand._ When a repeated chain becomes multiline, equivalent chain operators **SHOULD** align within that chain and **MUST NOT** align across a different chain or nested call.

#### 5.2.2 Indices, Postfixes, And Suffices [META-SUFFIX]

**[META-SUFFIX-01]** An _index, slice, dereference, generic application, call suffix,_ or other _postfix form_ **SHOULD** remain visually attached to the subject it modifies. _Repeated suffixes_ **_SHOULD_** _align by their opening token when doing so exposes their shared subject._

#### 5.2.3 Signatures [META-CALL]

**[META-CALL-01]** _Calls_ and _declarations_ **MUST** have _separate list policies._ **_Arguments_** are _expressions_ supplied by a _caller;_ **_parameters_** are _declarations_ owned by a _signature._ _Similar delimiters_ **_MUST NOT_** _erase that distinction._

#### 5.2.4 Declarations And Their Modifiers [META-DECL]

**[META-DECL-01]** A declaration’s _annotations, modifiers, type components, prefix markers, name, default, constraints,_ and _body_ **MUST** remain parts of that declaration. _A profile_ **_MUST_** _define their legal and canonical relative order without implying that every combination is valid._

#### 5.2.5 Assignment Operations [META-ASSIGN]

**[META-ASSIGN-01]** A profile **MUST** distinguish _assignment operators_ from visually similar _declaration separators, key/value separators, named-argument separators, pattern binders,_ and _arm separators._ _Each grammatical role_ **_MUST_** _own its own break and alignment rule._

#### 5.2.6 Prefix And Postfix Operators [META-PREFIX]

**[META-PREFIX-01]** Prefix and postfix operators **MUST** remain attached to their grammatical operands. A repeated prefix marker **MAY** receive an alignment column when that column exposes a real parallel relationship, such as negated conditions or reference parameters.

#### 5.2.7 Literals [META-LITERAL]

**[META-LITERAL-01]** A data literal **MUST** establish its own item context. Key/value alignment **MAY** occur within a related group, but source order **MUST NOT** be changed when order affects evaluation, iteration, serialization, matching, or user-visible output.

#### 5.2.8 Callables [META-CALLABLE]

**[META-CALLABLE-01]** A closure, lambda, callable reference, anonymous type, or comparable expression with an internal signature or body **MUST** remain 1 composite operand of its container. Its parameters, captures, return declaration, body expression, and block body **MUST** retain their own local contexts.

#### 5.2.9 Typing [META-TYPE]

**[META-TYPE-01]** A profile with type syntax **MUST** distinguish atomic types from composite type relations. Multiline types **SHOULD** use the same hierarchy engine as expressions when their grammar has comparable precedence and grouping.

#### 5.2.10 Modifiers And Annotations [META-MOD]

**[META-MOD-01]** Modifier and annotation order **MUST** be defined per declaration target. The ordering rule **MUST** specify relative order only and **MUST NOT** imply permission for grammatically or semantically invalid combinations.

#### 5.2.11 Body Ownership [META-BODY]

**[META-BODY-01]** A _named declaration, anonymous declaration, block expression,_ or _control body_ **MUST** expose the _ownership_ of its body. The profile **MUST** define _opener placement, body indentation, empty-body form, closer placement,_ and the attachment of _enclosing punctuation._

#### 5.2.12 Controls [META-CONTROL]

**[META-CONTROL-01]** Each control header **MUST** establish a context _separate_ from its body. _Branches, case groups, match arms, handlers,_ and _loop clauses_ **MUST** establish independent contexts to prevent alignment obligations from crossing unrelated control-flow paths.

**[META-CONTROL-02]** A profile **MUST** define when _braces_ or equivalent _block delimiters_ are mandatory, how _chained branches_ or handlers _join,_ how _fallthrough_ is identified, and how control-transfer statements terminate.

#### 5.2.13 Pipelines, Chains, And Dataflow [META-PIPE]

**[META-PIPE-01]** A _pipeline, composition chain,_ or _staged dataflow_ expression **MUST** preserve stage order and **_MUST_** _treat each stage as 1 operand._ Multiline stages **SHOULD** return to a common _pipeline base_ after completing their internal context.

#### 5.2.14 Embedding, Templates, Macros, And Preprocessors [META-EMBED]

**[META-EMBED-01]** _Embedded languages, template regions, macro bodies, preprocessor continuations,_ and _generated spans_ **MUST** identify which language grammar owns each area. _A host-language alignment rule_ **_MUST NOT_** _rewrite guest-language content without an explicit nested profile._

### 5.3. Comments And Documentation [META-COMMENT]

**[META-COMMENT-01]** A comment attached to a construct **SHOULD** move with that construct when formatting changes its position. _Formatting_ **_MUST NOT_** _make a comment appear to describe a different operand, branch, declaration, or list item._

**[META-COMMENT-02]** A trailing comment **MUST NOT** force unrelated lines into a shared alignment column. _When it causes overflow or obscures ownership, it_ **_SHOULD_** _become a preceding comment if that movement preserves its meaning and tool interpretation._

**[META-COMMENT-03]** _Documentation comments, compiler directives, formatter controls, lint suppressions,_ and _generated-region markers_ **MUST** retain the adjacency and shape required by their consumers.

### 5.4. Naming And Organization [META-ORG]

_Naming, import ordering, member ordering,_ and _file organization_ often vary more across languages and ecosystems than _expression layout_ does. Nevertheless, rules governing them may belong in a language profile where applicable. Due to the inherent variety, universality is difficult, but not impossible:

**[META-ORG-01]** A profile **MUST** either define or explicitly delegate _naming, import ordering, declaration ordering, file naming,_ and _file organization._ _It_ **_MUST NOT_** _infer conventions from examples alone._

**[META-ORG-02]** _Reordering declarations, imports, fields, cases, mapping entries, or branches_ **_MUST_** _preserve initialization order, lookup behavior, reflection order, visibility, side effects, and generated output._

## 6. Versions, Deprecations, And Compatibility [META-VERSION]

**[META-VERSION-01]** A profile **MUST** state its minimum, preferred, and maximum validated language versions or editions. _Syntax unavailable at the minimum target_ **_MUST NOT_** _be required without an explicit version-gated rule._

**[META-VERSION-02]** Deprecated lexical or grammatical forms **MUST** be governed by _1 centralized policy._ Construct-specific sections **SHOULD** refer to that policy _instead of duplicating its prohibitions and replacements._

**[META-VERSION-03]** A deprecation policy **MUST** distinguish _deprecated syntax_ from _deprecated APIs, runtime behavior, configuration,_ and _tooling._ It **MUST** identify the supported replacement _and any case in which replacement may alter behavior._

**[META-VERSION-04]** A fixture whose explicit purpose is to detect deprecated or rejected syntax **MAY** contain that syntax only when isolated from production loading and marked as nonprecedential.

**[META-VERSION-05]** When a new language version adds syntax, the profile **MUST** update its _language-facts table, token inventory, operator or delimiter tables, construct inventory,_ and _validation fixtures_ before declaring the version supported.

## 7. Validation

### 7.1. Source Validation [META-VALIDATE]

**[META-VALIDATE-01]** _Every normative syntax example in a language profile_ **_SHOULD_** _be parsed or compiled by a supported implementation._ Fragments that cannot stand alone **MUST** identify their assumed context or be embedded in a validation fixture.

**[META-VALIDATE-02]** _Formatting validation_ **_MUST_** _verify that the formatted program preserves parsing and behavior._ Where practical, it **SHOULD** compare syntax trees, run semantic tests, or use another representation appropriate to the language.

**[META-VALIDATE-03]** Automated checks **SHOULD** cover:

- duplicate and malformed rule identifiers;
- unresolved rule references;
- code fences;
- tabs, trailing whitespace, and line limits;
- parsing or compilation across supported versions;
- warnings and deprecations selected by the profile;
- formatter or linter agreement;
- semantic regression tests; and
- idempotence after repeated formatting.

**[META-VALIDATE-04]** A profile **SHOULD** include _positive fixtures_ for _compact and multiline forms, nested contexts, long protected units, comments, version-gated syntax,_ and each _construct-specific exception._ It **SHOULD** include _negative fixtures_ for _ambiguous, deprecated,_ or _forbidden forms._

### 7.2. Rule Validation [META-AUDIT]

**[META-AUDIT-01]** _Each rule_ **_MUST_** _be testable or objectively reviewable._ A rule that depends on judgment **MUST** name the decision boundary, such as _line length, grammatical ownership, conceptual grouping,_ or _semantic risk._

**[META-AUDIT-02]** Two rules **MUST NOT** independently own the same requirement. When requirements overlap, _1 rule_ **_MUST_** _own the behavior and the others_ **_MUST_** _reference it._

**[META-AUDIT-03]** A profile **MUST** be audited for contradictions among _general rules, construct-specific exceptions, examples, formatter configuration,_ and _supported versions._

**[META-AUDIT-04]** Optional alignment **MUST** have a bounded group and a _deterministic escape_ for excessive padding. _Optional formatting_ **_MUST NOT_** _make conformance impossible to decide._

## 8. Maintenance [META-MAINT]

**[META-MAINT-01]** Rule identifiers **MUST** remain stable after publication. A retired identifier **MUST NOT** be reused for a different requirement; it **SHOULD** remain as a tombstone or migration note when external references may exist.

**[META-MAINT-02]** A rule change **MUST** update its _examples, cross-references, fixtures, formatter configuration,_ and _version notes_ in the _same change._

**[META-MAINT-03]** A _construct-specific rule_ that specializes or overrides a general rule **MUST** identify that _general rule, state the grammar, tooling, or clarifying reason for the exception,_ and _identify how the exception is validated._ If it cannot identify a general rule, the author **SHOULD** first determine whether the missing concept belongs in the rules for general layout.

**[META-MAINT-04]** Examples **SHOULD** be minimal and nonduplicative. A canonical example **SHOULD** live with the rule that owns its behavior; worked examples elsewhere **SHOULD** demonstrate interaction among multiple rules.

**[META-MAINT-05]** A profile change **SHOULD** include a short rationale recording the _grammar fact, ambiguity, maintenance concern,_ or _language-version change_ that motivated it.

**[META-MAINT-06]** Mechanical migrations **SHOULD** be separated from semantic changes when practical. _A formatting migration_ **_MUST NOT_** _include unannounced behavior changes._

## 9. Language Profile Template

The following outline is nonnormative but provides a reusable starting point. A profile **MAY** rename or divide sections while preserving the required decisions.

```
# <Language And Dialect> Code Style

**Status:** <Draft Or Published> — <Version>
**Language target:** <Minimum Through Maximum>
**Formatter ownership:** <Tool And Version, Or None>

## 1. Scope And Conformance

### 1.1. Included Source
### 1.2. Excluded Source
### 1.3. Normative Language
### 1.4. Priorities
### 1.5. Version And Deprecation Policy

## 2. Lexical Profile

### 2.1. Style Tokens
### 2.2. Protected Source Units
### 2.3. Required Adjacency
### 2.4. Comments And Embedded Languages

## 3. Physical Layout

### 3.1. Whitespace And Indentation
### 3.2. Line Length
### 3.3. Structural And Alignment Bases
### 3.4. Operator Hierarchy
### 3.5. Break Propagation
### 3.6. Delimiter Matrix
### 3.7. List Policies

## 4. Construct-Specific Rules

### 4.1. Names, Access, And Suffixes
### 4.2. Calls And Construction
### 4.3. Declarations And Parameters
### 4.4. Callable Or Anonymous Forms
### 4.5. Literals And Destructuring
### 4.6. Types, Modifiers, And Annotations
### 4.7. Aggregate And Module Declarations
### 4.8. Operators And Assignments
### 4.9. Conditionals, Loops, And Matching
### 4.10. Errors, Handlers, And Transfers
### 4.11. Imports, Directives, And Metaprogramming

## 5. Naming And Organization

## 6. Validation Fixtures

## 7. Non-normative Worked Examples
```

### 9.1. Completion Criteria [META-COMP]

**[META-COMP-01]** A language profile is _complete_ only when:

- its scope and supported versions are explicit;
- its language-facts, operator, delimiter, and construct inventories are populated;
- every applicable construct family has an owning rule or explicit delegation;
- every exception refers to its general rule, reason, and validation;
- every rule identifier is unique and every reference resolves;
- representative examples parse or compile;
- deprecated and version-gated syntax is tested;
- formatting is behavior-preserving and idempotent; and
- required formatter, linter, and compiler versions are recorded.