feat: LLM readability layer — llms.txt, serve-markdown, and CDN caching

amplify.yml

@@ -0,0 +1,61 @@
+version: 1
+frontend:
+  phases:
+    preBuild:
+      commands:
+        - yarn install
+        - yarn docusaurus clean-api-docs all --all-versions
+        - yarn docusaurus gen-api-docs all --all-versions
+    build:
+      commands:
+        - yarn build
+  artifacts:
+    baseDirectory: build
+    files:
+      - "**/*"
+  cache:
+    paths:
+      - node_modules/**/*
+
+  # Explicit rewrite rules so Amplify's SPA fallback never intercepts agent-facing
+  # static files (.md pages, llms-full.txt, skill.md).  Rules are evaluated in
+  # order; the SPA catch-all should come last if you ever add one.
+  customRules:
+    - source: "**/*.md"
+      target: "**/*.md"
+      status: "200"
+    - source: "/llms-full.txt"
+      target: "/llms-full.txt"
+      status: "200"
+    - source: "/skill.md"
+      target: "/skill.md"
+      status: "200"
+
+customHeaders:
+  # HTML pages — short CDN TTL so deployments propagate within 1 hour
+  - pattern: "**/*.html"
+    headers:
+      - key: Cache-Control
+        value: "public, max-age=0, s-maxage=3500, must-revalidate"
+
+  # JS / CSS / fonts — content-addressed filenames, safe to cache forever
+  - pattern: "**/assets/**"
+    headers:
+      - key: Cache-Control
+        value: "public, max-age=31536000, immutable"
+
+  # Raw Markdown files — short TTL + correct Content-Type for LLM agents
+  - pattern: "**/*.md"
+    headers:
+      - key: Cache-Control
+        value: "public, max-age=0, s-maxage=3500, must-revalidate"
+      - key: Content-Type
+        value: "text/markdown; charset=utf-8"
+
+  # llms.txt and llms-full.txt — short TTL so index updates are visible quickly
+  - pattern: "**/llms*.txt"
+    headers:
+      - key: Cache-Control
+        value: "public, max-age=0, s-maxage=3500, must-revalidate"
+      - key: Content-Type
+        value: "text/plain; charset=utf-8"

cartesi-rollups_versioned_docs/version-1.5/rollups-apis/rollup/cartesi-rollup-http-api.info.mdx

@@ -85,7 +85,7 @@ while True:
 ```
 
 In production mode, if the dApp exits the Rollups initialization script will register a Rollup Exception.
-See [/exception](#api-Default-registerException).
+See [/exception](./register-exception).
 
 In host mode, the Cartesi Rollups infrastructure is not able to detect that the dApp exited.
 It is up to the dApp developer to re-launch the dApp.

cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/notices.md

@@ -186,5 +186,5 @@ std::string handle_advance(httplib::Client &cli, picojson::value data)
 </Tabs>
 
 :::note querying notices
-Frontend clients can query notices using a JSON RPC API exposed by Cartesi Nodes. [Refer to the documentation here](../../development/query-outputs.md#query-all-notices) to query notices from the rollup server.
+Frontend clients can query notices using a JSON RPC API exposed by Cartesi Nodes. [Refer to the documentation here](../../development/query-outputs.md#query-all-notices-and-vouchers) to query notices from the rollup server.
 :::

cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/types.md

@@ -467,4 +467,5 @@ Result for getting the node version.
 ```typescript
 interface NodeVersionResult {
   data: string; // Semantic version format
-} 
+}
+```

cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/cartesi-rollup-http-api.info.mdx

@@ -85,7 +85,7 @@ while True:
 ```
 
 In production mode, if the dApp exits the Rollups initialization script will register a Rollup Exception.
-See [/exception](#api-Default-registerException).
+See [/exception](./register-exception).
 
 In host mode, the Cartesi Rollups infrastructure is not able to detect that the dApp exited.
 It is up to the dApp developer to re-launch the dApp.

cartesi-rollups_versioned_docs/version-2.0/resources/migration-guide.md

@@ -9,16 +9,16 @@ Rollups node v2.0 introduces some major changes in how the node works internally
 
 ### My back-end...
 - handles ERC-20 token deposit inputs. See the [ERC-20 token deposit inputs](#erc-20-token-deposit-inputs) section.
-- handles application address relay inputs. See the [Application address](#application-address) section.
-- generates Ether withdrawal vouchers. See the [Ether withdrawal vouchers](#ether-withdrawal-vouchers) section.
+- handles application address relay inputs. See the Application address section.
+- generates Ether withdrawal vouchers. See the Ether withdrawal vouchers section.
 
 ### My front-end...
-- validates notices. See the [Outputs](#outputs) section.
-- executes vouchers. See the [Outputs](#outputs) section.
-- listens to voucher execution events. See the [Outputs](#outputs) section.
-- checks if a voucher was executed. See the [Outputs](#outputs) section.
-- uses inspect calls. See the [Inspect calls](#inspect-calls) section.
-- uses JSON-RPC queries. See the [JSON queries](#jsonrpc-queries) section.
+- validates notices. See the Outputs section.
+- executes vouchers. See the Outputs section.
+- listens to voucher execution events. See the Outputs section.
+- checks if a voucher was executed. See the Outputs section.
+- uses inspect calls. See the Inspect calls section.
+- uses JSON-RPC queries. See the JSON queries section.
 
 :::note
 If your application uses a high-level framework(ex. Deroll, Rollmelette etc.) for either backend or frontend, check if the framework has already implemented the changes described in this guide.

cartesi-rollups_versioned_docs/version-2.0/tutorials/calculator.md

@@ -342,7 +342,7 @@ for (const output of outputs) {
 }
 ```
 
-You can also [query a notice based on its input index](../development/query-outputs.md#query-a-single-notice).
+You can also [query a notice based on its input index](../development/query-outputs.md#query-a-single-notice-or-voucher).
 
 Congratulations, you have successfully built a dApp on Cartesi Rollups!
 

customHttp.yml

@@ -0,0 +1,28 @@
+customHeaders:
+  # Hashed assets (JS, CSS, images) — content-addressed filenames, safe to cache forever
+  - pattern: "**/assets/**"
+    headers:
+      - key: Cache-Control
+        value: "public, max-age=31536000, immutable"
+
+  # HTML pages — short CDN TTL so deployments propagate quickly
+  - pattern: "**/*.html"
+    headers:
+      - key: Cache-Control
+        value: "public, max-age=0, s-maxage=3500, must-revalidate"
+
+  # Raw Markdown files — short TTL + correct MIME type for LLM agents
+  - pattern: "**/*.md"
+    headers:
+      - key: Cache-Control
+        value: "public, max-age=0, s-maxage=3500, must-revalidate"
+      - key: Content-Type
+        value: "text/markdown; charset=utf-8"
+
+  # llms.txt and llms-full.txt — short TTL so index updates are visible quickly
+  - pattern: "**/llms*.txt"
+    headers:
+      - key: Cache-Control
+        value: "public, max-age=0, s-maxage=3500, must-revalidate"
+      - key: Content-Type
+        value: "text/plain; charset=utf-8"

docs/cartesi-machine/host/cmdline.md

@@ -564,7 +564,7 @@ d8b96e5b7f6f459e9cb6a2f41bf276c7b85c10cd4662c04cbbb365434726c0a0
 ```
 As expected, the hash values match.
 
-The <a name="sibling-hashes"> `sibling_hashes` </a> array contains the hashes of the siblings to all nodes in the path from the root all the way down to the target node (excluding the root, which has no sibling).
+The <a id="sibling-hashes"> `sibling_hashes` </a> array contains the hashes of the siblings to all nodes in the path from the root all the way down to the target node (excluding the root, which has no sibling).
 In a process explained in the [blockchain perspective](../blockchain/hash.md), using the `address` field, the `target_hash` hash, and the `sibling_hashes` array, it is possible to go up the tree computing the hashes along the path, until the root hash is produced.
 If the root hash obtained by this process matches the expected root hash, the proof is valid.
 Otherwise, something is amiss.

docs/cartesi-machine/host/lua.md

@@ -494,7 +494,7 @@ Note that the `machine:run()` method can return precociously for a variety of re
 The `iflags` CSR contains a bit `H` that is set to true whenever the machine is halted, and a bit `Y` that is set to true whenever the machine has yielded manual.
 The `machine:read_iflags_H()` and `machine:read_iflags_Y()` methods return the value of these bits, respectively, and the loop breaks if any of them is set.
 
-<a name="run-cat-foo-bar"></a>
+<a id="run-cat-foo-bar"></a>
 
 For example, to run the configuration stored in `./config/cat-foo-bar.lua` (assuming `./foo.ext2` is available) simply run
 

docs/cartesi-machine/target/architecture.md

@@ -573,7 +573,7 @@ When an application identifies an inspect-state request, it obtains the query fr
 While processing inspect-state requests, the application can emit vouchers, or exceptions.
 It writes data for all these to the Rollup TX buffer memory range and sends the appropriate command to the HTIF yield device.
 
-The format for all these request and response data are as follows: <a title="#rollup-format"></a>
+The format for all these request and response data are as follows: <a id="rollup-format"></a>
 
 <center>
 <table>

docs/tutorials/gpg-verify/larger-files.md

@@ -12,7 +12,7 @@ title: Processing larger files
 
 As discussed in the [documentation](/compute/logger_drive), Cartesi Compute provides a _Logger service_ that is capable of publishing and retrieving data more efficiently to and from the blockchain. More specifically, this service stores the information as _call data_ and allows it to be split into smaller chunks, thus enabling storage of data that is larger than a single block's limit. Although not suitable for direct usage within smart contracts themselves, this strategy is perfect for passing along on-chain data _references_ to off-chain components, which can then download it from the blockchain for processing.
 
-On top of the Logger service, Cartesi Compute also features integrated IPFS support in its nodes. As also explained in the [documentation](/compute/logger_drive/#ipfs-integrated-support), generally speaking IPFS alone is not sufficient to ensure data availability for verifying a computation, since it cannot guarantee that the validator nodes will be able to access the data when needed. However, in Cartesi Compute it is possible to upload the data to IPFS, and then trigger the Logger service automatically as a fallback should any node fail to retrieve it. As such, for the vast majority of cases in which actors do not misbehave, and for specific scenarios for which IPFS data availability is not an issue, using IPFS can prevent data from ever having to be published to the blockchain, with obvious benefits in terms of cost and performance.
+On top of the Logger service, Cartesi Compute also features integrated IPFS support in its nodes. As also explained in the [documentation](/compute/logger_drive/#integrated-ipfs-support), generally speaking IPFS alone is not sufficient to ensure data availability for verifying a computation, since it cannot guarantee that the validator nodes will be able to access the data when needed. However, in Cartesi Compute it is possible to upload the data to IPFS, and then trigger the Logger service automatically as a fallback should any node fail to retrieve it. As such, for the vast majority of cases in which actors do not misbehave, and for specific scenarios for which IPFS data availability is not an issue, using IPFS can prevent data from ever having to be published to the blockchain, with obvious benefits in terms of cost and performance.
 
 In this context, we will now build upon our [previous dApp implementation](../gpg-verify/full-dapp.md) and add a method that uses the Logger and IPFS services to allow a larger file's signature to be verified using Cartesi Compute.