===================================
= 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:

- Fix the language, dialect, version range, source scope, and required tools.

- Record language facts, protected units, operator relations, delimiters, and
  legal break positions.

- Adopt each portable default or document its narrow language-specific
  adaptation under META-PORT-03.

- Populate the construct inventory and give every distinct behavior 1 owning
  rule.

- Add minimal examples, exception records, formatter configuration, and
  validation fixtures.

- 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
local 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.