# View Contract Demos

These demos exercise the finalized View Contract stack in `lib/view.tri`:
portable View Trees/checkable typed-program nodes, structural View flow checks,
runtime guarded Views, checked-exec, source annotations, and module-boundary
View metadata.

## End-user guide

Start here. `demos/viewContracts.tri` is written with normal source annotation
sugar and reads as a short guide to View Contracts: motivating structural
mismatches, explaining plain Views, noting why this is not a full static type
system, and building a custom `NonEmptyList` guarded View.

```bash
tricu check demos/viewContracts.tri
```

Expected output:

```text
ok
```

## Complete explicit demo

`demos/viewContracts/complete.tri` shows the same layer from the portable
View Tree/checkable-program side. It uses explicit builders such as
`typedValue`, `typedRequire`, and `typedApply`, and demonstrates contextual guard
diagnostics, observation composition, reachability, and malformed guard output.

```bash
tricu eval demos/viewContracts/complete.tri -f decode
```

## Portable checker self-tests

Runs the checker self-test suite carried as ordinary `tricu` code.

```bash
tricu eval demos/viewContracts/selfTests.tri -f decode
```

Expected output is a list of `"ok"` strings.

## Diagnostic rendering

Shows a strict-mode structural View failure rendered for humans.

```bash
tricu eval demos/viewContracts/diagnostic.tri -f decode
```

Expected output:

```text
"symbol 162 expected List Bool but got List String"
```

## Stdlib-shaped contracts

Checks successful higher-order contracts shaped like common stdlib APIs.

```bash
tricu eval demos/viewContracts/stdlibContracts.tri -f decode
```

Expected output:

```text
["ok", "ok", "ok", "ok", "ok"]
```

These examples are structural View checks, not runtime guarded checks.

## Frontend emission layer

`frontendEmission/` documents the portable artifact shape a frontend can emit
after parsing/elaboration. The `*.source.txt` files are pseudo-source; the
matching `*.emitted.tri` files are explicit typed-program builder output.

This layer is still instructive because it shows the exact bridge between source
syntax and portable View Tree/checkable metadata.

## Source syntax sugar

The `sourceSyntax/` demos use ergonomic annotations and the `tricu check`
frontend. The frontend lowers annotations to the same typed-program nodes used by
the explicit demos above, then executes checked-exec so guarded annotations fail
through the portable runner.

Successful check:

```bash
tricu check demos/viewContracts/sourceSyntax/success.tri
```

Expected output:

```text
ok
```

Labeled diagnostic check:

```bash
tricu check demos/viewContracts/sourceSyntax/failure.tri
```

Expected first failing diagnostic:

```text
symbol 4 (x) expected Bool but got String
```

If the first definition is fixed or removed, the later application-result
failure demonstrates callee-aware labels:

```text
symbol 3 (g application result) expected String but got Bool
```

## Module boundary layer

`modules/` shows producer-checked module export Views flowing into a consumer
check as module-boundary evidence. During auto-build, annotated exports are
checked before the module manifest alias is published. Consumers then use the
manifest's View Contract metadata as assumptions, while compatibility is still
judged by `lib/view.tri`.

```bash
tricu check demos/viewContracts/modules/success.tri
# ok

tricu check demos/viewContracts/modules/failure.tri
# symbol 3 (Util.toString application result) expected Bool but got String
```