Add AI rules through agent docs

.claude/CLAUDE.md

@@ -0,0 +1 @@
+@../AGENTS.md

.github/copilot-instructions.md

@@ -0,0 +1,5 @@
+# BuildingSync Schema - Copilot Instructions
+
+All repository rules for AI agents live in [AGENTS.md](../AGENTS.md). Read and follow it before making changes.
+
+File-scoped rules in [.github/instructions/](instructions/) apply automatically to `BuildingSync.xsd` and `proposals/**/*.md`.

.github/instructions/proposals.instructions.md

@@ -0,0 +1,15 @@
+---
+applyTo: "proposals/**/*.md"
+description: "Format and process for BuildingSync feature proposals"
+---
+
+# Writing a proposal
+
+Follow [proposals/README.md](../../proposals/README.md).
+
+- Location: `proposals/<year of submission>/<Title Case Name>.md` (e.g. `proposals/2026/Add Field-assembled DX system to DXSystemType.md`).
+- Required sections, in order: `## Overview` (brief summary), `## Justification` (evidence the change is needed and beneficial), `## Implementation` (exact XSD changes: element paths, types, enumerations, documentation text). Optional: `## References`.
+- State whether the change is breaking or non-breaking per [docs/versioning.md](../../docs/versioning.md); breaking proposals must discuss severity of the breakage and the migration path.
+- Reference the GitHub issue it addresses.
+- The proposal and its implementation may be in the same PR or in separate PRs; separate PRs are not required. Either way, the proposal is discussed and accepted/rejected before merge; the project lead decides if no consensus.
+- Markdown is formatted by prettier via `poetry run pre-commit run --all-files`.

.github/instructions/schema-xsd.instructions.md

@@ -0,0 +1,47 @@
+---
+applyTo: "BuildingSync.xsd"
+description: "Conventions for editing the BuildingSync XSD"
+---
+
+# Editing BuildingSync.xsd
+
+Read the surrounding region first and keep edits minimal; do not reformat unrelated content. Classify the change (breaking / non-breaking / patch, per [docs/versioning.md](../../docs/versioning.md)) before editing.
+
+## Structure
+
+- Indent with 2 spaces, never tabs; no XMLSpy comments (run `bundle exec rake remove_tabs` after editing).
+- Never use `xs:complexContent` (test-enforced); compose with named types, `xs:sequence`, and `ref`.
+- New elements are optional (`minOccurs="0"`) unless a breaking change is intended and approved.
+- Inserting a new optional element into an `xs:sequence` is fine; moving or reordering existing elements is breaking.
+- `xs:element` names must be unique across the schema. To reuse a structure, define a named `xs:complexType`/`xs:simpleType` (suffix `Type`) or a global element used via `ref="auc:..."`.
+- Global names must not collide with gbXML global names.
+- Do not modify the header (`version` attribute, title documentation, root `version` enumeration) outside a release; see [docs/release_instructions.md](../../docs/release_instructions.md).
+
+## Documentation
+
+- Every new element, type, and enumeration-bearing element gets `<xs:annotation><xs:documentation>`.
+- Write a clear definition sentence; put units in parentheses at the end, e.g. `... gross floor area. (ft2)`, `(kBtu/ft2)`, `($)`, `(cfm)`, `(W/ft2)`.
+- Documentation-only changes are patch-level.
+
+## Enumerations
+
+- Adding a value is non-breaking; removing or renaming one is breaking (deprecate instead).
+- Follow the existing wording/casing style of sibling values; include `Other` and `Unknown` where siblings do.
+
+## Common patterns
+
+- Identity: `<xs:attribute name="ID" type="xs:ID" use="required"/>`.
+- Links: element with `<xs:attribute name="IDref" type="xs:IDREF" use="required"/>`; document the valid target in [docs/linking_elements.md](../../docs/linking_elements.md).
+- Data provenance: `<xs:attribute ref="auc:Source"/>`; system state: `ref="auc:Status"`.
+- Extensibility: `<xs:element ref="auc:UserDefinedFields" minOccurs="0"/>`.
+- gbXML content uses the `gbxml` prefix (see [docs/gbXML_reference.md](../../docs/gbXML_reference.md)).
+
+## Deprecation
+
+- Never remove elements outside a major version (XSD header Rule #1).
+- Mark deprecated items in documentation: `WARNING: This element is being deprecated, use <Replacement> instead.` (for enum values: `WARNING: This enumeration is being deprecated, use ... instead`).
+- Update examples to use the replacement.
+
+## Verify
+
+`bundle exec rake` and `bundle exec rake generate_data_dictionary` must pass.

.gitignore

@@ -49,3 +49,4 @@ gbxml.xsd
 *.bak
 *.backup
 *.tmp
+/tmp

docs/notebooks/bsync_examples/Small-Office-Level-1.md

@@ -835,11 +835,11 @@ utilities += ng_ut
 
 Now that we have a current building measured scenario, we want to declare energy and monthly billing data. Per Std 211 6.1.2.1, a minimum of 12 months (preferably up to 3 years) of energy use data is required. The mechanical system of the small office prototype is a heatpump air handler with natural gas backup. We know that Missoula is cold, so likely it will use natural gas backup at some point during its operation. We run an example simulation to get estimates for this, which come out as follows:
 
-| Resource Type          | Jan     | Feb     | Mar     | Apr    | May     | Jun     | Jul     | Aug     | Sep     | Oct     | Nov     | Dec     |
+| Resource Type | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
 | ---------------------- | ------- | ------- | ------- | ------ | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ----- |
-| Electricity (kWh)      | 6792.89 | 5841.75 | 6025.19 | 4985.3 | 5184.04 | 5358.55 | 5755.67 | 5981.78 | 5401.94 | 5225.84 | 5672.15 | 6291.63 |
-| Natural Gas (MMBtu)    | 5.7     | 4.01    | 0.58    | 0.4    | 0.02    | 0       | 0       | 0       | 0       | 0.01    | 0.36    | 6.08    | 17.16 |
-| GHG Emissions (MtCO2e) | 250.0   | 240.0   | 260.0   | 250.0  | 260.0   | 230.0   | 280.0   | 270.0   | 260.0   | 250.0   | 240.0   | 250.0   |
+| Electricity (kWh) | 6792.89 | 5841.75 | 6025.19 | 4985.3 | 5184.04 | 5358.55 | 5755.67 | 5981.78 | 5401.94 | 5225.84 | 5672.15 | 6291.63 |
+| Natural Gas (MMBtu) | 5.7 | 4.01 | 0.58 | 0.4 | 0.02 | 0 | 0 | 0 | 0 | 0.01 | 0.36 | 6.08 | 17.16 |
+| GHG Emissions (MtCO2e) | 250.0 | 240.0 | 260.0 | 250.0 | 260.0 | 230.0 | 280.0 | 270.0 | 260.0 | 250.0 | 240.0 | 250.0 |
 
 In BuildingSync land, we need to declare an resource use for each resource type. Standard, allowable enumerations exist for this already. We do this as follows:
 

proposals/README.md

@@ -13,11 +13,11 @@ BuildingSync is intended to be a standardized language for commercial building e
 The process is semi-formal and is not intended to be rigidly applied. The procedure is roughly comprised of the following steps:
 
 1. The proposer writes a Markdown document, modeled on this document, that succinctly describes the changes that are proposed.
-2. The proposer creates a GitHub pull request that adds the document to the proposal directory in a subdirectory named for the year in which the submission is being made (e.g. proposals/2018/Add_New_Feature_XYZ.md).
+2. The proposer creates a GitHub pull request that adds the document to the proposal directory in a subdirectory named for the year in which the submission is being made (e.g. proposals/2018/Add_New_Feature_XYZ.md). The pull request may also include the implementation of the proposed changes; separate proposal and implementation pull requests are not required.
 3. The proposer, the BuildingSync team, and other stakeholders and interested parties discuss the proposal and make modifications using the GitHub pull request discussion facility. At the conclusion of this process, the proposal is accepted or rejected. If a clear consensus cannot be reached to accept or reject the proposal, the project lead will decide if the proposal should be accepted.
-4. If the proposal is accepted, new GitHub issues are created to track the development (or a GitHub Project if it is a larger proposal), and a developer is assigned to the issues (not necessarily the proposer or a BuildingSync team member). The "proposal" pull request is then merged.
-5. The change is made by the developer in accordance with the contribution policy.
-6. The developer initiates a GitHub pull request when the changes are complete. The BuildingSync team and other stakeholders and interested parties will review the implementation and request necessary changes. If consensus can be reached that the implementation is acceptable, the pull request is merged and tracking items are closed. If a clear consensus cannot be reached to accept or reject the implementation, the project lead will decide if the implementation should be accepted.
+4. If the proposal is accepted and the pull request already includes the implementation, the implementation is reviewed as described in step 6 and the pull request is merged once both are accepted. Otherwise, new GitHub issues are created to track the development (or a GitHub Project if it is a larger proposal), a developer is assigned to the issues (not necessarily the proposer or a BuildingSync team member), and the "proposal" pull request is merged.
+5. If not already done, the change is made by the developer in accordance with the contribution policy.
+6. The implementation is reviewed in its pull request (either the combined pull request or a separate one initiated by the developer when the changes are complete). The BuildingSync team and other stakeholders and interested parties will review the implementation and request necessary changes. If consensus can be reached that the implementation is acceptable, the pull request is merged and tracking items are closed. If a clear consensus cannot be reached to accept or reject the implementation, the project lead will decide if the implementation should be accepted.
 
 The proposal document must contain at least three sections: **Overview**, **Justification**, and **Implementation**. The purpose of each of the sections is as follows: