# Contributing to Class Profiles Prototype 0.1

Prototype 0.1 is a Calendar-first discussion artifact, not a standard. The most useful contribution is evidence that the proposed contract is clear, implementable, or wrong.

## Useful contributions now

- **Ambiguity reports:** identify a file and anchor, then describe two reasonable conflicting interpretations.
- **Fixture corrections:** show how an implementation could satisfy a case while violating its intended behavior, or why a case is nondeterministic.
- **Implementation reports:** record what happened when implementing the profile directly or projecting an existing backend.
- **Contract reductions:** show that a smaller Core surface still completes the stated Calendar jobs.
- **Degradation cases:** identify optional behavior that could disappear or be substituted without an observable result.
- **Prior art:** link a primary source and explain which part of the prototype it should constrain, replace, or remove.
- **Documentation fixes:** correct an inaccurate statement or make the status and evidence boundary clearer.

Ideas for other capability classes are welcome as discussion. Prototype 0.1 remains Calendar-only until the current model has evidence from independent implementations.

## Report an ambiguity

Open an issue titled:

```text
ambiguity: <file>#<anchor>
```

Include:

1. the two interpretations;
2. the observable difference between them;
3. a proposed fixture or wording change, if you have one.

An ambiguity in contract text is a specification defect. Resolve it with an executable case when possible.

## Change rules

1. [`profiles/calendar/profile.json`](profiles/calendar/profile.json) is authoritative within the prototype.
2. A behavioral promise requires a fixture.
3. Change the descriptor and affected fixtures together when semantics change.
4. Core is all-or-nothing; partial support is not a baseline Claim.
5. An unavailable facet or vendor member must follow its declared degradation behavior.
6. Direct and projected implementations are held to the same cases.
7. Preserve stable anchors in the numbered specification chapters.
8. Do not add conformance badges, passing Claims, or receipts; no official runner exists.
9. Keep public copy inquiry-led and distinguish simulation, repository validation, implementation evidence, and adoption.

Style terminology is defined in [`GLOSSARY.md`](GLOSSARY.md). Related work already considered is recorded in [`PRIOR-ART.md`](PRIOR-ART.md).

## Validate a change

Install dependencies once with `npm ci`, then run:

```powershell
npm test
pwsh ./scripts/validate.ps1
```

The first command builds and checks the website and its deterministic simulation. The second validates repository artifacts and links. Neither command tests an external implementation for conformance.

See [`DEVELOPMENT.md`](DEVELOPMENT.md) for command details and delivery mechanics.

Contributions are accepted under the repository’s [Apache-2.0 license](LICENSE).