# Description of Changes
Adds primary keys to procedural views in C++. This mirrors the work from
#5111, #5246, and #5327 adding the feature and the docs changes.
# API and ABI breaking changes
None
# Expected complexity level and risk
3
# Testing
- [x] Equivalent tests as were added in #5111 and #5246 for rust,
typescript, and C#
# Description of Changes
Was forgotten while migrating to the QueryBuilder i suppose.
Closes#5073
Maybe @clockwork-tien could lend a hand again in reviewing? ^^
# API and ABI breaking changes
None
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
Works in my project :>
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] Type Error goes away when using .eq(uuid)
---------
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
Fixes the `Release Notifications` workflow startup failure seen in
<https://github.com/clockworklabs/SpacetimeDB/actions/runs/27775721225/workflow>.
The internal announcement job referenced `needs: on-release`, but no
`on-release` job exists in `.github/workflows/tag-release.yml`, so the
workflow failed before scheduling any jobs. This removes the dangling
dependency and gates the internal Discord announcement to real `release`
events so manual `workflow_dispatch` dry runs do not try to send an
internal release announcement using missing release-event fields.
# API and ABI breaking changes
None. This only changes GitHub Actions configuration.
# Expected complexity level and risk
1 - Low complexity. The change is limited to one workflow job
dependency/condition.
# Testing
- [x] Parsed `.github/workflows/tag-release.yml` as YAML.
- [x] Checked that all remaining `needs:` targets in
`.github/workflows/tag-release.yml` refer to existing jobs.
- [x] Ran `git diff --check`.
- [ ] Optional reviewer check: run the workflow manually with the
default dry-run inputs after merge.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Creates a new GitHub action that triggers any time a `Release` on the
SpacetimeDB repo changes to the `published` state.
When this triggers, the workflow will take information from that
release, and build a message from it, in the form of:
```
**SpacetimeDB ${RELEASE_TAG}**
View the full release notes:
${RELEASE_URL}
${RELEASE_BODY}
```
And send that message to the SpacetimeDB Public Discord Webhook.
Note: This PR itself does not setup or configure the Discord Webhook,
and relies on the Webhook URL already being available.
# API and ABI breaking changes
No API or ABI changes, this is only related to GitHub tooling.
# Expected complexity level and risk
1 - Low complexity. The only risk is in sending garbage messages to the
Discord URL if this automation is improperly configured.
# Testing
- [X] Ran a local version of similar code to test formatting. No testing
of this GitHub Action has been performed.
---------
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
# Description of Changes
Removes all references to `Promise.withResolvers` from the codebase
since it's not supported universally and replaces it with the classic
pre-ES2024 deferred pattern. See #5031 and #5342.
Also adds a lint to avoid re-introducing it in the future.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
...
# Description of Changes
Adds a merge-queue fast path for CI when the synthetic merge-group
commit has the same tree as the queued PR head.
The new `merge_queue_noop` job parses the PR number from the merge-group
ref, resolves the PR head SHA, and compares that tree to `GITHUB_SHA`.
If there is no diff, the expensive CI jobs are skipped as duplicate
work. Matrix jobs with required per-matrix check names get lightweight
no-op counterparts so branch protection still sees the expected
successful check names.
# API and ABI breaking changes
None.
# Expected complexity level and risk
2. This is limited to GitHub Actions wiring, but it interacts with merge
queue semantics and required check names. The implementation
intentionally falls back to normal CI if it cannot parse the PR number
or resolve the PR head.
# Testing
- [x] Parsed `.github/workflows/ci.yml` with Ruby YAML.
- [x] Ran `git diff --check`.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Refactors the Rust smoketest helper surface so publish and subscribe
variants use builders instead of parallel helper methods.
- Replaces `publish_module*` helper variants with `Smoketest::publish()`
and fluent options for name, clear, current database, break clients,
stdin, replicas, organization, and source modules.
- Replaces `subscribe_*` / `subscribe_background*` variants with
`Smoketest::subscribe(...).expect_rows(...).confirmed(...).background()`.
- Updates smoketest call sites to the builder APIs.
# API and ABI breaking changes
Internal smoketest helper API change only. No product API or ABI
changes.
# Expected complexity level and risk
2
This touches many smoketest call sites, but the underlying CLI command
behavior remains centralized in the same helper internals.
# Testing
- [x] Existing CI passes
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
This is an attempt at fixing a SIGABRT that sometimes happens when
running the standalone integration tests.
It's not clear exactly what causes it, however one thing that may have
contributed to it was that previously the tests did not initiate a clean
shutdown of the database.
Some modules schedule repeating work in `init`, and it's not obvious to
me that in flight operations will exit cleanly if we just drop all of
the database/runtime handles at once.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1
# Testing
This is a testing fix.
# Description of Changes
- spacetime init --template without arg prints templates list and link
to website
# Screenshot
<img width="696" height="392" alt="screenshot"
src="https://github.com/user-attachments/assets/98e87537-554b-411b-96ab-3ceb9a6a9d45"
/>
<!-- Please describe your change, mention any related tickets, and so on
here. -->
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] I tested the changes
# Description of Changes
Closes#5250#4636 introduced a regression where the ProcedureContext used to include
the sender and connection_id from the caller while now it is always
empty (which is wrong)
Correct it.
Also fully migrate to `database_identity` which was forgotten about so i
deprecated it for procedures (since they are now stable) and just
changed it for HttpHandlers (because they are still unstable)
@gefjon since you did the lil woopsie (ugh pinging you again lol hope im
not annoying haha)
# API and ABI breaking changes
Breaking the HttpHandler function which is unstable.
Restoring behaviour of 2.3 which got lost with 2.4.
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1. Trivial refactoring
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] The caller identity is there again for Procedures.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Reviewing recent benchmark runs, it appears that #5071 probably
regressed TPS by around 3-5%. I don't want to revert that change because
it has implications for replication, and so for now we'll just live with
the slight regression.
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
N/A
# Description of Changes
Attempted to fix this test in #5343, but we're still getting SIGKILLS,
so ignoring for now. This will require more investigation to fix. I've
included what I believe is the reason in the help text and created
[this](#5362) tracker to unskip.
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
N/A
# Description of Changes
Use an isolated server process per SDK test instead of a single process
for all of the tests. In addition to reducing the memory footprint of
each test run, this should also allow for more parallelism among the
individual tests.
# API and ABI breaking changes
None
# Expected complexity level and risk
1.5
# Testing
The SDK test suite should continue to work
# API and ABI breaking changes
None. Docs-only change.
# Expected complexity level and risk
1 - trivial documentation fix, no code or behaviour change.
# Testing
- [x] Confirmed accessor names against the SDK source:
`database_identity()` (Rust/C++), `databaseIdentity` (TS),
`DatabaseIdentity` (C#); the old forms are marked deprecated/obsolete in
bindings.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
The reducer-context cheat-sheet and the "Context Properties Reference"
tables still listed `ctx.identity` / `ctx.identity()` as the accessor
for the module's own identity. That accessor was deprecated in favour of
`databaseIdentity` / `database_identity()` / `DatabaseIdentity`, and the
troubleshooting guide added in c70d00246 (#5142) documented the
deprecation but missed updating these other references — these stray
updates should have landed there. This brings all four language tabs in
line with the non-deprecated accessor.
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
## What changed
Adds an explicit checkout step before `dorny/paths-filter` in the
Internal Tests workflow.
## Why
`dorny/paths-filter@v3` needs a git working tree for `push` events. The
Internal Tests workflow ran it before any checkout, so every `push` run
on `master` failed immediately in `Detect non-docs changes` with:
```text
fatal: not a git repository (or any of the parent directories): .git
```
This only showed up consistently on `master` because those runs are
`push` events. On `pull_request` events, `dorny/paths-filter` can use
the GitHub pull request files API with the PR number, so it does not
need a local checkout for the same file detection path.
Adding checkout gives the action a repository when it handles `push`
events, while leaving PR behavior unchanged.
## Testing
- `git diff --check`
- PR #5295 `Internal Tests` job completed `Checkout` and `Detect
non-docs changes` successfully, then moved on to private dispatch/wait.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
We believe this docker build is completely unused. This docker container
is different than the docker build that we send out for releases which
is the one users actually end up using. This specific docker build used
to be for internal deploys but we have not used it in a very long time
now, probably more than a year or two.
# API and ABI breaking changes
None - this is just a CI change.
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1 - just a CI change
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- Not tested but we sync'd on this in the discord and there were no
objections from the devops team or @joshua-spacetime .
---------
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
This removes the `spacetimedb-update` check specifically on arm. This
test doesn't have a whole lot of value because we're already covering
Linux + Windows on x86 and then macOS on aarch64. Removing this will
allow us to decom the arm runner.
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
None - just a CI change
# Expected complexity level and risk
1
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- I have not tested this but me and Zeke sync'd on this and we think it
makes sense.
# Description of Changes
Moves `RelationalDB` and related database code into a new
`spacetimedb-engine` crate.
The main motivation is to tighten dependency control around the engine
layer and isolate `RelationalDB`
behind a crate boundary.
- Majority of this PR is code-motion.
- Removes direct production dependence on `tokio` from
`spacetimedb-engine`.
- Keeps `tokio` only as a dev-dependency for test-only code in
`spacetimedb-engine`.
- This is intended to be a structural refactor only and should not
result in any functional change in
production.
- Adds a CI check to ensure `spacetimedb-engine` continues to compile in
simulation mode
# API and ABI breaking changes
NA
# Expected complexity level and risk
1.5.
# Testing
Existing tests should be enough.
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
Fix TypeScript inference for generated object shapes containing
`Option<T>` fields.
Previously, generated TypeScript represented an optional SATS field as a
required object key whose value could be `undefined`:
```ts
{
foo: string | undefined;
}
```
This PR changes those generated shapes to make the key itself optional:
```ts
{
foo?: string | undefined;
}
```
The original issue was reported in #4516: generated TypeScript
reducer/procedure calls required users to pass explicit `undefined`
values for omitted optional arguments. This PR fixes that for reducer
and procedure params, and also applies the same optional-key inference
to generated row shapes.
This is a fresh bot-owned replacement for stalled PR #4518.
## Examples
A reducer with an optional argument now generates a TypeScript call
shape where the optional key may be omitted:
```rust
#[spacetimedb::reducer]
pub fn update_category(
_ctx: &spacetimedb::ReducerContext,
id: u64,
name: String,
button_text: Option<String>,
) {
// ...
}
```
Before this PR, generated TypeScript callers had to pass the optional
argument explicitly:
```ts
await conn.reducers.updateCategory({
id: 1n,
name: 'updated category name',
buttonText: undefined,
});
```
After this PR, generated TypeScript callers can omit the optional key:
```ts
await conn.reducers.updateCategory({
id: 1n,
name: 'updated category name',
});
```
A table row with an optional column also changes its generated
TypeScript row shape:
```rust
#[spacetimedb::table(name = player, public)]
pub struct Player {
#[primary_key]
pub id: u64,
pub display_name: String,
pub alias: Option<String>,
}
```
Before this PR, generated TypeScript treated `alias` as a required key:
```ts
type Player = {
id: bigint;
displayName: string;
alias: string | undefined;
};
```
After this PR, generated TypeScript treats `alias` as an optional key:
```ts
type Player = {
id: bigint;
displayName: string;
alias?: string | undefined;
};
```
# API and ABI breaking changes
This is a TypeScript source/API breaking change for generated type
shapes that contain `Option<T>` fields. It is not an ABI or wire-format
break: SATS encoding and decoding of `Option<T>` are unchanged.
The breaking edge is structural TypeScript code that requires optional
SATS fields to exist as object properties. For example, code like this
may stop compiling:
```ts
type RequiresAliasProperty = {
id: bigint;
displayName: string;
alias: string | undefined;
};
function renderPlayer(player: RequiresAliasProperty) {
return player.alias ?? player.displayName;
}
conn.db.player.onInsert((_ctx, player) => {
renderPlayer(player);
});
```
With this PR, the generated `player` row has `alias?: string |
undefined`, so it is not assignable to a type requiring an `alias`
property.
Code using `Required<GeneratedRow>`, explicit generated-row mirror
interfaces, or generic constraints that require optional SATS fields to
be present as object keys may need to loosen those keys to optional
properties.
Reducer and procedure params are primarily loosened by this change.
Existing calls that pass `undefined` explicitly should continue to
typecheck, while calls can now omit optional keys.
# Expected complexity level and risk
2.
The change is contained to TypeScript type inference and generated
TypeScript test coverage. The main risk is source compatibility for
TypeScript consumers that depend on the old required-key shape for
`Option<T>` fields.
# Testing
- [x] `pnpm --filter @clockworklabs/test-app build`
- [x] `pnpm test`
- [x] targeted `prettier --check`
- [x] `git diff --check`
Closes#4516.
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
Fixes an OOM kill in the proptest `bsatn_invalid_wont_decode`.
`bsatn_invalid_wont_decode` generates arbitrary invalid bytes, proves
validation fails, then still calls full AlgebraicValue::decode. For
generated array-like types, decode reads a u32 length prefix, and the
generic array visitor then reserves that capacity. But because they're
random bytes, this could cause a huge initial allocation which could OOM
kill the test process.
Now the visitor reserves a smaller initial capacity instead of assuming
the binary input data is well formed.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1
# Testing
This should fix the flaky `spacetimedb-sats` `Test Suite` failures that
occasionally end in a SIGKILL.
# Description of Changes
Review #5287 first.
This patch updates view backing table schemas to have a single private
column `arg_hash`. Previously sender-scoped views had a `sender` column
for the calling identity, however now that's been replaced with a single
unified `arg_hash` column that encodes the calling identity within it.
When we add parameterized views, the view args will also be encoded in
this hash and stored in this column.
This column exists for both anonymous and sender scoped views meaning
that the backing tables for all views now have the same number of
private columns - one.
This hash is now used as a runtime variable that the query engine uses
to evaluate view table scans.
In order to keep the diff small, this patch does update view read sets
with this new hash value. That change has a larger blast radius and will
be done in the next set of changes.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
2
# Testing
Existing coverage.
# Description of Changes
Adding a stub version of this workflow so we can test it with
`workflow_dispatch`
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1
# Testing
None, can't test until it's merged
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
* Bump version to 2.6.0
# API and ABI breaking changes
None
# Expected complexity level and risk
* 1 - this is just a version bump
# Testing
- [X] Version number is correct (`2.6.0`)
- [X] BSL license file has been updated with the new date and version
number
# Description of Changes
All of rust, C#, and typescript are included.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1
# Testing
N/A - docs only change
# Description of Changes
Makes runtime parameters explicit in query plans (prerequisite for
parameterized views).
As part of this change, `sender` is no longer baked directly into query
plans as a literal value. Instead it is represented as a parameter in
the query plan. Values are supplied at runtime via a variable
environment called `ExecutionParams`.
Note, parameterized plans are still not shared across subscriptions yet.
That will be done in a follow up.
This is mostly a mechanical change. The majority of the diff is just
threading runtime params/variables through various call sites.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
...
# Testing
Existing coverage
# Description of Changes
Restores `CLA Gate` as a repository-owned commit status on the actual
target SHA.
The merged workflow tried to use the Actions job result for `status`
events. Those runs are attached to the default-branch SHA, so a
`license/cla` status on a PR head can trigger the workflow without
creating any required context on the PR commit. This change mirrors the
`license/cla` result back to `CLA Gate` on the PR or merge-group SHA.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1. This is a narrow workflow fix for the required CLA check context.
# Testing
- [x] Ruby YAML parse for `.github/workflows/cla-gate.yml`
- [x] `git diff --check`
- [ ] Confirm a new `license/cla` status posts `CLA Gate` on the same PR
head SHA
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
Runtime specific changes from
https://github.com/clockworklabs/SpacetimeDB/pull/5113.
- `spacetimedb-runtime` enforces exactly one feature at compile time:
`tokio` or `simulation`. It rejects both-enabled and neither-enabled
builds explicitly.
- This also keeps `tokio::sync` re-exported from runtime, look at code
comment for reasoning.
# API and ABI breaking changes
NA
# Expected complexity level and risk
1
## Summary
- keep the CLA Gate workflow using `cargo ci cla-assistant status` for
CLA Assistant lookups
- stop mirroring pull request/status `license/cla` results into a custom
`CLA Gate` commit status
- use a plain `pull_request` trigger for PR checks, and keep merge-group
status publishing for synthetic queue SHAs
- let the Actions job pass when `license/cla` is success and fail when
it is missing or non-success
## Notes
Merge-group handling is left as-is. This PR intentionally keeps the
helper command and only changes the workflow behavior needed to avoid
the custom status mirror on PR/status events.
## Testing
- `cargo fmt --all`
- `cargo check -p ci`
- `cargo ci self-docs --check`
- Ruby YAML parse
- `git diff --check`
`actionlint` unavailable locally.
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
## Summary
- Add a Discord announcement job for published GitHub releases.
- Use `DISCORD_WEBHOOK_RELEASE_CHANNEL_URL` so the target channel can be
configured as a GitHub secret.
- Run the announcement job even if Docker `latest` retagging fails, and
include the retag result in the message.
## Verification
- `ruby -e 'require "yaml";
YAML.load_file(".github/workflows/tag-release.yml")'`
- `git diff --check`
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
## Summary
- Add a CLA Gate workflow that publishes a repository-owned commit
status.
- Mirror CLA Assistant license/cla status on pull requests and status
events.
- Publish CLA Gate=success on merge_group runs, because entries have
already passed PR checks before entering the queue.
## Required settings change after merge
- Remove license/cla from required checks.
- Add CLA Gate as the required CLA check.
This keeps CLA enforcement before merge queue while removing CLA
Assistant from the merge-group critical path.
## Test plan
- Parsed .github/workflows/cla-gate.yml with Ruby YAML loader.
- Ran git diff --check.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
## Summary
- Fix TypeScript view examples to use `ctx.sender` as a property,
matching the server SDK `ViewCtx` API.
- Update the architecture overview TypeScript view snippet to use
`players.rowType` and `undefined` for optional view returns.
- Clarify shared `ViewContext` prose so it does not imply every language
uses a callable `ctx.sender()` API.
- Improve docs agent-readiness metadata:
- publish `/docs/robots.txt` with a docs sitemap directive and
Content-Signal policy
- add Markdown alternate links for the existing `/docs/llms.txt` and
`/docs/llms-full.txt` outputs
- generate `/.well-known/agent-skills`-style discovery metadata under
`/docs/.well-known/agent-skills/` from the repo's existing `skills/`
source files during docs builds
## Validation
- `pnpm --dir docs build`
- `pnpm --dir docs typecheck`
- Verified the docs build emits `robots.txt` and
`.well-known/agent-skills/index.json`.
- Verified generated Agent Skills SHA-256 digests match the emitted
`SKILL.md` artifacts.
## Notes
The Cloudflare agent-readiness scan for `spacetimedb.com` still depends
on the root/marketing host exposing root-level files such as
`/robots.txt`, `/sitemap.xml`, and
`/.well-known/agent-skills/index.json`. This PR makes the docs origin
produce the corresponding docs-scoped artifacts at `/docs/...`; the root
host can route or mirror these if we want the exact `spacetimedb.com`
scan to pick them up.
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: rain <rain@rain.local>
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Shubham Mishra