@t4h.framework/fs 0.12.2 → 0.13.1

package/.ai/skills/framework-fs/SKILL.md

@@ -2,7 +2,7 @@
 name: framework-fs
 description: >-
   Guides correct use of @t4h.framework/fs in T4H Framework workflows: the
-  FileSystemClaim abstraction that the package activities (http, jsx) use to
+  FileSystemClaim abstraction that the package activities (http, pdf) use to
   read/write files, the Binary result workflows consume, and runtime providers.
   A workflow never implements Binary itself — see the framework-fs-write skill.
   Use when a workflow orchestrates file-backed package activities, consuming
@@ -31,12 +31,9 @@ import {
   read, FileReadActivity, type FileReadOptions,
   // turn workflow content into a Binary — see the framework-fs-write skill
   write, FileWriteActivity, type FileWriteOptions,
-  ByteDelimiterScanner, type FileSplitDelimiter, type ByteRange, type ByteTrim,
 } from '@t4h.framework/fs'
 ```
 
-Do not import from internal paths such as `src/FileSystemClaim.ts` in application code.
-
 ---
 
 ## FileSystemClaim contract
@@ -66,7 +63,7 @@ export abstract class FileSystemClaim {
 |--------|---------|
 | `write(path, readable, contentType?)` | Persist stream or buffer at `path`; return a `Binary` handle (metadata + `stream()`). When `contentType` is omitted, infer it from the path. |
 | `read(path)` | Load an existing file at `path`; return a `Binary` handle. |
-| `slice(binary, range, encoding?)` | A view over a byte range of an existing binary, **without copying data**. When `encoding` is set, the runtime hydrates the slice as a decoded string instead of a binary — this is how `split` children receive plain strings. Implementations must **compose ranges**: slicing a slice is relative to it, and the stored range is absolute against the underlying file. |
+| `slice(binary, range, encoding?)` | A view over a byte range of an existing binary, **without copying data**. When `encoding` is set, the runtime hydrates the slice as a decoded string instead of a binary — this is how `read` returns a window as a string. Implementations must **compose ranges**: slicing a slice is relative to it, and the stored range is absolute against the underlying file. |
 
 All methods may return synchronously or as a `Promise`. Implementations choose storage layout; callers should only rely on the returned `Binary` API.
 
@@ -81,12 +78,14 @@ export abstract class Binary {
 ```
 
 The package activities return this `Binary` to your workflow — e.g. an `http`
-response `Body` is backed by it. Consume it with `stream()` (or the higher-level
-`body.json()` / `text()` that packages expose):
+response `Body` is backed by it. The workflow only passes the `Binary` to
+another activity. An activity reads it in `run`:
 
 ```typescript
-const stream = await binary.stream()
-// consume stream (e.g. stream.toArray() then Buffer.concat)
+async run(file: Binary) {
+  const stream = await file.stream()
+  // consume stream (e.g. stream.toArray() then Buffer.concat)
+}
 ```
 
 ---
@@ -95,7 +94,7 @@ const stream = await binary.stream()
 
 Workflows never call `FileSystemClaim` directly. File I/O happens inside the
 **ready-made package activities** that already own the claim — the `http` client
-persists response bodies, jsx render activities write their output — and you
+persists response bodies, the pdf render activity writes its output — and you
 read the resulting `Binary` (e.g. `await res.body.json()` / `text()`). Your only
 responsibility is that the runtime **registers a provider** (below). See
 **Known consumers** for which package primitives to orchestrate.
@@ -120,7 +119,7 @@ The runtime must register a concrete subclass:
 { provide: FileSystemClaim, value: new MyFileSystemClaimImpl() }
 ```
 
-`MyFileSystemClaimImpl` must extend `FileSystemClaim` and implement `write` and `read`. The README uses `LocalFileSystemClaimImpl` as a **placeholder name** for that implementation; there is no class by that name in this monorepo.
+`FileSystemClaim` is abstract, so `tsc` rejects a subclass that does not implement `write`, `read` and `slice`. The README uses `LocalFileSystemClaimImpl` as a **placeholder name** for that implementation; there is no class by that name in this monorepo.
 
 ---
 
@@ -131,8 +130,8 @@ These packages depend on `@t4h.framework/fs` and declare `FileSystemClaim`; read
 | Package | Usage |
 |---------|--------|
 | `@t4h.framework/http` | The HTTP activity persists response bodies to `fs` and returns them wrapped in a `Body` — you read them with `res.body.json()` / `text()`. |
-| `@t4h.framework/jsx` | Render activities write their output to `fs` and hand back a `Binary` you consume in the workflow. |
-| `@t4h.framework/fs` itself | `FileSplitActivity` persists the durable copy and slices it by ranges; `FileJoinActivity` streams batch results into a new file; `FileReadActivity` slices (or streams, when the binary is not file-backed) a small window into a string. See the `framework-fs-split` skill. |
+| `@t4h.framework/pdf` | The render activity writes the PDF to `fs` and hands back a `Binary` you consume in the workflow. |
+| `@t4h.framework/fs` itself | `FileSplitActivity` streams the source and hands its slices to `startMany` as strings; `FileJoinActivity` streams batch results into a new file; `FileReadActivity` slices (or streams, when the binary is not file-backed) a small window into a string. See the `framework-fs-split` skill. |
 
 Orchestrate these package primitives from your workflow; the `fs` write/read happens inside them.
 
@@ -145,8 +144,8 @@ Test the **workflow** with `TestWorkflowEnvironment` from
 claims the triggered activities need, e.g. `HttpClientRequestClaim` for an HTTP
 call). See the **framework-workflow-testing** skill for the harness API.
 
-Subclassing `Binary` is legitimate **only here**, in a test double standing in
-for the claim — never in workflow or App code.
+`@t4h.framework/core/no-binary-subclass` rejects a `Binary` subclass out of a
+test file. A test double for the claim can extend `Binary`:
 
 ```typescript
 import { Readable } from 'node:stream'
@@ -191,13 +190,12 @@ Assert `mockWrite` was called with the expected path and body when relevant.
 
 ## Implementing a custom FileSystemClaim
 
-1. **Extend** `FileSystemClaim` from `@t4h.framework/fs`.
-2. **Return** a `Binary` subclass (or core-compatible `Binary`) from `write` and `read` with correct `contentType`, `contentLength`, and `stream()`.
-3. **Accept** `Readable | Buffer` and the optional `contentType` in `write`
-   (match the abstract signature), falling back to inferring the content type
-   from the path when it is omitted.
-4. **Register** `{ provide: FileSystemClaim, value: new YourImpl() }` in the runtime (tests use `mockClaim(FileSystemClaim, ...)` instead).
-5. **Keep paths deterministic** when activities replay — unpredictable temp paths are fine if only `Binary` metadata is serialized and replay re-executes `write`; know your serializer/replay story if `path` is persisted.
+1. **Extend** `FileSystemClaim` from `@t4h.framework/fs`. `tsc` checks the method signatures.
+2. **Return** a `Binary` from `write`, `read` and `slice` with correct `contentType`, `contentLength`, and `stream()`.
+3. **Infer** the content type from the path when `write` gets no `contentType`.
+4. **Compose** ranges in `slice`: a slice of a slice is relative to it.
+5. **Register** `{ provide: FileSystemClaim, value: new YourImpl() }` in the runtime (tests use `mockClaim(FileSystemClaim, ...)` instead).
+6. **Keep paths deterministic** when activities replay — unpredictable temp paths are fine if only `Binary` metadata is serialized and replay re-executes `write`; know your serializer/replay story if `path` is persisted.
 
 ---
 
@@ -206,14 +204,15 @@ Assert `mockWrite` was called with the expected path and body when relevant.
 1. Add `"@t4h.framework/fs": "workspace:^"` (or published version) to app `dependencies` when activities use `FileSystemClaim`.
 2. Ensure **`@t4h.framework/core`** is available (peer of `fs`).
 3. Register **`FileSystemClaim`** in the runtime or test `claims` array.
-4. Orchestrate file I/O through the package activities that own `FileSystemClaim` (http, jsx) — workflow code never declares an activity or accesses `this.claims.fs`.
+4. Orchestrate file I/O through the package activities that own `FileSystemClaim` (http, pdf) — workflow code never declares an activity or accesses `this.claims.fs`.
 
 ---
 
 ## Anti-patterns
 
-- Importing from `@t4h.framework/fs` paths other than the package export (`FileSystemClaim` only).
-- Omitting `FileSystemClaim` from providers while using `@t4h.framework/http` or `@t4h.framework/jsx` activities that require `fs`.
+- A deep import. The package exports only its entry, so a deep import fails in `tsc`.
+- Calling `stream()` in a workflow, or in an activity `constructor`, `toInput` or `toOutput`. The `no-binary-stream-outside-activity` rule of `@t4h.framework/core/eslint` reports it.
+- A missing `FileSystemClaim` provider. The activity throws `ClaimProviderNotFoundException` when it reads the claim.
 - Assuming `packages/fs` ships a concrete disk/S3 implementation — it does not; implement and register `FileSystemClaim` in your runtime or test harness.
 
 ---
@@ -224,4 +223,4 @@ Assert `mockWrite` was called with the expected path and body when relevant.
 - `framework-fs-write` — `write`: turn workflow content into a `Binary`, and why an App must never implement `Binary`.
 - `framework-core` — `Claim`, `Binary`, and the `TestWorkflowEnvironment` testing harness.
 - `framework-http` — HTTP activities that persist bodies via `FileSystemClaim`.
-- `framework-jsx` — render activities that write/read via `fs`.
+- `framework-pdf` — the render activity that writes PDFs via `fs`.

package/.ai/skills/framework-fs-split/SKILL.md

@@ -2,7 +2,7 @@
 name: framework-fs-split
 description: >-
   Guides correct use of `split`, `join` and `read` from @t4h.framework/fs:
-  fanning one large file out into a batch of workflows (one per byte-range
+  fanning one large file out into a batch of workflows (one per
   slice), folding the batch results back into a single file, and reading small
   byte windows (headers, trailers) into the workflow — with O(1) parent
   history and bounded memory regardless of file size. Use whenever a workflow
@@ -20,8 +20,7 @@ description: >-
 # `split` / `join` / `read` — file fan-out, fold and windows for workflows
 
 `split` turns **one file into a batch of workflows**: it streams the file once,
-cuts it into **byte-range slices** (never copying slice content), starts one
-child workflow per slice, and **suspends the parent until every child is
+cuts it into slices, starts one child workflow per slice, and **suspends the parent until every child is
 terminal**. `join` is the inverse: it folds the batch results back into a
 single file, streaming one result at a time.
 
@@ -36,7 +35,7 @@ const processRecord = new Workflow(
   },
 )
 
-const main = new Workflow(fileSchema, async (file: Binary) => {
+const main = new Workflow({ id: 'main', schema: fileSchema }, async (file: Binary) => {
   const header = await read(file, { range: { start: 0, end: 240 } })
   // header: string — recorded in history, never re-read on replay
 
@@ -62,13 +61,12 @@ Package path: `framework/packages/fs`. Import only from the package root.
 Everything here exists to keep the parent history **O(1)** whatever the file
 size:
 
-1. `split` reads the source stream **exactly once, worker side**: the same
-   pass persists a durable copy through `FileSystemClaim.write` while a byte
-   scanner records slice offsets. No slice content is materialized.
-2. Children receive **range views** over the durable copy
-   (`FileSystemClaim.slice`); the runtime hydrates each slice only inside that
-   child's own run — as a plain decoded string when the child's schema is
-   `Type.String()`.
+1. `split` reads the source once, worker side: it cuts records, drops the ones
+   `where` rejects, groups the rest by `every` and hands each slice to the
+   batch as a decoded string as soon as it is complete. Nothing collects the
+   slices, and no copy of the file is written.
+2. Each child receives its slice as a plain string — what its
+   `Type.String()` schema declares.
 3. The parent resumes with only `WorkflowBatchRef { id, count }`. Per-child
    results are **never aggregated onto the ref**: they live with each child
    run.
@@ -128,17 +126,16 @@ the next slice. Forgetting `{ next: 2 }` silently strips the record type code
 from every slice.
 
 Offsets are always computed over **raw bytes** (never decoded characters), so
-multi-byte encodings cannot skew the ranges a ranged download will use.
+multi-byte encodings cannot skew the cuts.
 
 ### Other options
 
 | Option | Default | Behavior |
 |--------|---------|----------|
-| `every` | `1` | Cut only every N delimiter occurrences — groups N records per child. One million lines with `every: 10_000` start 100 children, each receiving a raw block (inner delimiters untouched) to iterate locally. `keep` arithmetic applies only at actual cut points. |
+| `every` | `1` | Cut only every N delimiter occurrences — groups N records per child. One million lines with `every: 10_000` start 100 children, each receiving a raw block (inner delimiters untouched) to iterate locally. `keep` arithmetic applies only at actual cut points. A slice over 3 MiB makes the split throw a `RangeError`; lower `every`. |
 | `trim` | none | `{ start?, end? }` **bytes** cut off each end of the file before scanning — a positional header/trailer. Byte-based on purpose: a record-start delimiter (`'\n10'`) fuses the trailer into the last record's slice, so a record-count skip would drop a valid record along with it. Trimmed content never becomes a slice nor counts toward `every`; fetch it with `read`. Positional layouts make the byte counts constants — getting them right is the caller's business. |
 | `skipEmpty` | `true` | Drops zero-length slices (consecutive delimiters, file starting/ending with one) so they never become child workflows. Turn off when slice index must align 1:1 with record position. "Empty" means zero bytes — a whitespace-only line is a regular slice. |
 | `encoding` | `'utf8'` | Converts the delimiter to bytes and decodes each slice into the string the child receives. |
-| `inlineMaxBytes` | `16_384` | A slice up to this many bytes is handed to the child as a string straight from the scan; a larger one as a reference to its byte range in the durable copy, read back where the child runs. Reading a few hundred bytes back costs a row lookup and a ranged object read per child, which is what a million-line split spends its CPU on. `0` hands every slice by range. Keep it well under the runtime's fan-out message budget (1 MiB by default). |
 | `timeoutInMs` | none | Max milliseconds to await the batch; on expiry the activity **rejects** (reason `timeout`) instead of suspending forever — the safety net for a child that never reaches a terminal state. |
 
 ---
@@ -185,16 +182,12 @@ const relevant = await join<InvoiceResult>(batch, {
 })
 ```
 
-Non-serializable filters are rejected eagerly at `toInput` (`TypeError`):
-functions (incl. `$where`), `RegExp` (incl. `$regex`), `undefined`, operators
-outside the subset — a dropped closure would make the replay filter
-differently than the first execution. Arbitrary predicates belong in a custom
-activity in project code (the function then lives in versioned code).
-MongoDB semantics apply: array fields match by containment (`{ tags: 'a' }`
-matches `['a', 'b']`), object values compare deeply, no type coercion. The
-query compiles once and runs inside the existing streaming loop over
-already-hydrated outputs — same memory profile; app-side (decides what enters
-the file, not what leaves the database).
+For an arbitrary predicate, write a custom activity in project code, so the
+function lives in versioned code. MongoDB semantics apply: array fields match
+by containment (`{ tags: 'a' }` matches `['a', 'b']`), object values compare
+deeply, no type coercion. The query compiles once and runs inside the existing
+streaming loop over already-hydrated outputs — same memory profile; app-side
+(decides what enters the file, not what leaves the database).
 
 ---
 
@@ -208,11 +201,9 @@ async function read(
 ```
 
 Reads a byte window of a `Binary` into the workflow as a decoded string. The
-output is recorded in history (replay never re-reads the file), so reads are
-**capped at 1 MiB** — this is the primitive for headers, trailers and single
-records; a data file flows through `split`, never through `read`. `range`
-defaults to the whole binary (same cap applies); `encoding` defaults to
-`'utf8'`.
+output is recorded in history (replay never re-reads the file). Use it for
+headers, trailers and single records; a data file flows through `split`.
+`range` defaults to the whole binary; `encoding` defaults to `'utf8'`.
 
 Two paths under the hood:
 
@@ -248,8 +239,9 @@ const batch = await split(file, processInvoice, {
 
 ## Runtime requirements
 
-- Claim providers: `FileSystemClaim` (with `slice`), `WorkflowClaim` (with
-  `startMany`), and `WorkflowBatchClaim` (from `@t4h.framework/core`).
+- Claim providers: `FileSystemClaim` (with `slice`, for `read` and `join`),
+  `WorkflowClaim` (with `startMany` reading an `AsyncIterable`), and
+  `WorkflowBatchClaim` (from `@t4h.framework/core`).
 - Production whitelist: `FileSplitActivity`, `FileJoinActivity`,
   `FileReadActivity` and core's `StartManyWorkflowsActivity` must be
   registered via `runtime.addActivity`.
@@ -271,26 +263,22 @@ from `src/activities/__tests__/`):
 
 ```typescript
 import { AsyncActivityResultPending, Claim, WorkflowBatchClaim, WorkflowBatchRef, WorkflowClaim } from '@t4h.framework/core'
-import { FileSplitActivity, FileSystemClaim, Split } from '@t4h.framework/fs'
+import { FileSplitActivity, Split } from '@t4h.framework/fs'
 
-const write = vi.fn(async (_path, readable) => durableBinary) // must consume the stream
-const slice = vi.fn((binary, range, encoding) => ({ binary, range, encoding }))
-const startMany = vi.fn(async (_wf, inputs) => new WorkflowBatchRef('batch-1', inputs.length))
+const inputs: unknown[] = []
+const startMany = vi.fn(async (_wf, slices: AsyncIterable<unknown>) => {
+  for await (const slice of slices) inputs.push(slice) // must consume the stream
+  return new WorkflowBatchRef('batch-1', inputs.length)
+})
 
 const result = await Claim.run(
-  [
-    { provide: FileSystemClaim, value: { write, slice } as never },
-    { provide: WorkflowClaim, value: { startMany } as never },
-  ],
-  () => {
-    const activity = new FileSplitActivity()
-    activity.id = 'activity-1'
-    return activity.bootstrap({ binary, workflow: 'child', options: { delimiter: Split.line() } })
-  },
+  [{ provide: WorkflowClaim, value: { startMany } as never }],
+  () =>
+    new FileSplitActivity().bootstrap({ binary, workflow: 'child', options: { delimiter: Split.line() } }),
 )
 
 expect(result).toBeInstanceOf(AsyncActivityResultPending)
-expect(slice).toHaveBeenCalledWith(durableBinary, { start: 0, end: 3 }, 'utf8')
+expect(inputs).toEqual(['foo', 'bar', 'baz'])
 ```
 
 For `join`, provide `WorkflowBatchClaim` as an async generator:
@@ -301,9 +289,8 @@ const outputs = vi.fn(async function* () {
 })
 ```
 
-Behaviors worth asserting because they regress easily: the durable copy keeps
-the original bytes; slices are views over the durable copy (not the source);
-`keep` arithmetic on positional cuts; the empty batch resolving immediately;
+Behaviors worth asserting because they regress easily: the source is streamed
+once; `keep` arithmetic on positional cuts; the empty batch resolving immediately;
 CSV escaping (quotes doubled, delimiter/newline wrapped); the status filter.
 
 ---
@@ -330,12 +317,11 @@ CSV escaping (quotes doubled, delimiter/newline wrapped); the status filter.
 - **Splitting a positional file without `trim`.** The header rides inside the
   first slice (with `every: N` it silently consumes a record slot) and the
   trailer fuses into the last one. Trim both ends; fetch them with `read`.
-- **Reading a data file with `read`.** The output lands in workflow history;
-  the 1 MiB cap is a guard, not a target. Records flow through `split`.
-- **Passing a function as a join filter.** Options serialize into history — a
-  closure cannot survive it, so `toInput` rejects functions, `$where`,
-  `RegExp` and out-of-subset operators with a `TypeError`. Use the `where`
-  sift subset or a custom activity whose predicate lives in versioned code.
+- **Reading a data file with `read`.** The output lands in workflow history.
+  Records flow through `split`. `read` throws a `RangeError` past 1 MiB.
+- **A non-serializable `where`.** `tsc` rejects a function through
+  `WorkflowBatchWhere`. `toInput` throws a `TypeError` for a function,
+  `$where`, a `RegExp`, `undefined` or an operator outside the subset.
 - **Hand-rolling the loop.** A stream-and-`startWorkflow` loop inside an
   activity re-parses on replay, misses the barrier, and pushes N entries into
   history.

package/.ai/skills/framework-fs-write/SKILL.md

@@ -37,7 +37,7 @@ Package path: `framework/packages/fs`. Import only from the package root.
 
 ## Never implement `Binary` yourself
 
-This is the rule this skill exists to enforce:
+`@t4h.framework/core/no-binary-subclass` rejects a class that extends `Binary`.
 
 ```typescript
 // ❌ NEVER — this class cannot be persisted
@@ -89,8 +89,9 @@ Symptoms of doing it by hand:
 - the activity is never persisted, the transaction rolls back, and the message
   ends up in the dead letter queue after the retries — the run stops mid-way
   with no obvious error in the workflow itself;
-- it may still "work" locally, because the dev server keeps values in memory
-  and never crosses a process boundary. **Passing locally proves nothing here.**
+- the dev server also throws `TypeError: Unsupported binary instance` when it
+  stores the activity input. It accepts only the `Binary` that its own claims
+  return.
 
 Current runtimes spool an unknown `Binary` to storage instead of failing, so a
 hand-rolled class may survive — but it pays a hidden copy, loses the content
@@ -121,13 +122,13 @@ the recorded `Binary` is returned.
 
 ## When to use it
 
-| Situation                                                                     | Use                                             |
-| ----------------------------------------------------------------------------- | ----------------------------------------------- |
-| Send content the workflow built (JSON, CSV, positional file) over SFTP/HTTP   | `write`                                         |
-| Read a small window of an existing file into the workflow                     | [`read`](./read) — see **framework-fs-split**   |
-| Fan a large file out into one workflow per record                             | `split` — see **framework-fs-split**            |
-| Fold a finished batch back into a file                                        | `join` — see **framework-fs-split**             |
-| Content already is a `Binary` (HTTP response body, `sftp.get`, `join` result) | pass it straight through — do not re-`write` it |
+| Situation                                                                     | Use                                           |
+| ----------------------------------------------------------------------------- | --------------------------------------------- |
+| Send content the workflow built (JSON, CSV, positional file) over SFTP/HTTP   | `write`                                       |
+| Read a small window of an existing file into the workflow                     | [`read`](./read) — see **framework-fs-split** |
+| Fan a large file out into one workflow per record                             | `split` — see **framework-fs-split**          |
+| Fold a finished batch back into a file                                        | `join` — see **framework-fs-split**           |
+| Content already is a `Binary` (HTTP response body, `sftp.get`, `join` result) | pass it straight through                      |
 
 ---
 
@@ -219,14 +220,11 @@ expect(write).toHaveBeenCalledWith('report.csv', expect.any(Buffer), 'text/csv')
 
 ## Anti-patterns
 
-- **Declaring a class that extends `Binary`** in an App. There is no valid
-  reason to; use `write`.
 - Helper functions like `stringToBinary(value)` that wrap content in a custom
   class — replace the implementation with `write`, keeping the helper name if
   it reads well.
-- `write`-ing a value that already is a `Binary` (an HTTP response body, a
-  `sftp.get` result, a `join` output) — that copies a file to obtain a
-  reference you already had.
+- `write`-ing a value that already is a `Binary`. `write` takes only
+  `string | Buffer`, so `tsc` rejects it.
 - Building a large file by concatenating records in memory and calling `write`
   once — use `split`/`join` instead.
 - Relying on the filename extension to set the content type when the consumer

package/CHANGELOG.md

@@ -1,5 +1,49 @@
 # @t4h.framework/fs
 
+## 0.13.1
+
+### Patch Changes
+
+- [#229](https://github.com/tech4humans-brasil/framework/pull/229) [`d4d7d97`](https://github.com/tech4humans-brasil/framework/commit/d4d7d973233ec1f4d78628a69283701b9a55fbf9) Thanks [@gusteycamargo](https://github.com/gusteycamargo)! - Fixes the published packages:
+  - harness: the published types import `typings/PublicProperties.js`, which was not in `dist`. `uuidv7` is now a dependency.
+  - dev: `tar` is now a dependency.
+  - fs: the published types of `FileSplitActivity` no longer import `typebox`, which `fs` does not depend on.
+
+- [#241](https://github.com/tech4humans-brasil/framework/pull/241) [`f6b8454`](https://github.com/tech4humans-brasil/framework/commit/f6b845484d22e7c8e7240fe2e113f1cdea7c8ce3) Thanks [@gusteycamargo](https://github.com/gusteycamargo)! - Adds seven rules to `@t4h.framework/core/eslint` and turns them on in `configs.recommended`:
+  - `no-io-in-workflow` reports `fetch` and calls to network, file, database and mail modules in a workflow and in the `constructor`, `toInput` and `toOutput` of an activity. It also reports `zlib` and `stream` calls there, because they work on the content in memory on each replay.
+  - `no-binary-subclass` reports a class that extends `Binary`.
+  - `no-framework-activity-in-app` reports `new` and `extends` on an activity of a framework package other than the core.
+  - `no-testing-import-in-source` reports an import of a `@t4h.framework/<package>/testing` entry out of a test file.
+  - `require-workflow-id` reports a `Workflow` with no `id`.
+  - `no-secret-to-string` reports a `Secret` that becomes a string.
+  - `no-literal-secret-in-authorization` reports a string literal in the `secret` or `clientSecret` field of an `Authorization`.
+
+  The package skills now name these rules in place of the text that the rules enforce. The docs and skills give each `Workflow` an `id`, read the HMAC secret from `EnvDesign`, and do not document a custom HTTP activity.
+
+- [#238](https://github.com/tech4humans-brasil/framework/pull/238) [`8567806`](https://github.com/tech4humans-brasil/framework/commit/8567806ec537288076c3a18a4816f26d58a67905) Thanks [@gusteycamargo](https://github.com/gusteycamargo)! - The `framework-fs` skill says to call `Binary.stream()` only in a method of an activity, not in the workflow.
+
+- [#240](https://github.com/tech4humans-brasil/framework/pull/240) [`0606115`](https://github.com/tech4humans-brasil/framework/commit/0606115e2e0baa994e9f0ed3559ee54ecac88e44) Thanks [@gusteycamargo](https://github.com/gusteycamargo)! - The skills do not repeat a rule that a lint rule, `tsc` or a runtime error already enforces. Each such rule is now one line that names the gate. The examples that broke a gate (`process.env`, `as any`, an inline secret, an `EnvDesign` in a workflow file, `ref.output` before `wait()`) are correct now.
+
+- [#228](https://github.com/tech4humans-brasil/framework/pull/228) [`d29e1ab`](https://github.com/tech4humans-brasil/framework/commit/d29e1ab29a039b13c3e4b075472bd615566ae75e) Thanks [@gusteycamargo](https://github.com/gusteycamargo)! - Uses exact types and `unknown` in place of `any`, and checks external data with guards.
+  - harness: the fix-issues prompt lists each sensor as `- checkTypes: PASS`. Before, it printed `- 0: [object Object]`.
+  - hmac: an algorithm name such as `constructor` throws `Unsupported algorithm`.
+  - oidc: a discovery response with no `introspection_endpoint`, or a null introspection body, throws a clear error.
+  - `HttpRequestActivity.toOutput` takes `HttpRequestActivityOutput` in place of `any`.
+
+## 0.13.0
+
+### Minor Changes
+
+- [#214](https://github.com/tech4humans-brasil/framework/pull/214) [`fc4db5f`](https://github.com/tech4humans-brasil/framework/commit/fc4db5fa01454a45a3727b76dbacc215aa6b3ab7) Thanks [@gusteycamargo](https://github.com/gusteycamargo)! - `split` reads the file once, as a stream: it cuts the records, drops the ones
+  `where` rejects, groups the rest by `every` and hands each slice to
+  `startMany` as a string as soon as it is complete. No durable copy of the file
+  is written and no slice is read back by range. A slice may take up to 3 MiB
+  (the same as the runtime's default limit for the input of a workflow
+  run); past that the split fails while it reads, naming the byte the slice
+  starts at, where `where` used to cap a record at 1 MiB and nothing capped a
+  slice. `inlineMaxBytes` is removed: every slice reaches its child as a
+  string. `ByteDelimiterScanner` is removed from the public API.
+
 ## 0.12.2
 
 ## 0.12.1

package/README.md

@@ -145,7 +145,7 @@ which stream through storage.
 
 ### split
 
-Splits a file into byte-range slices, starts one child workflow per slice as
+Splits a file into slices, starts one child workflow per slice as
 a single batch, and suspends the parent until every child is terminal —
 regardless of each child succeeding or failing (a rejected child never
 rejects the batch):
@@ -160,7 +160,7 @@ const processRecord = new Workflow(
   },
 )
 
-const main = new Workflow(fileSchema, async (file: Binary) => {
+const main = new Workflow({ id: 'main', schema: fileSchema }, async (file: Binary) => {
   const batch = await split(file, processRecord, {
     delimiter: Split.line(),
   })
@@ -170,14 +170,15 @@ const main = new Workflow(fileSchema, async (file: Binary) => {
 })
 ```
 
-The design goal is constant memory regardless of file size:
+The source is read once, as a stream:
 
-1. The source stream is read **exactly once**, worker side. The same pass
-   persists a durable copy through `FileSystemClaim.write` while a byte
-   scanner records the slice offsets — no slice content is ever materialized
-   in the activity.
-2. Children receive **range views** over the durable copy
-   (`FileSystemClaim.slice`).
+1. The source is read once, worker side: cut into records, filtered by
+   `where` when given, grouped by `every`, and each slice goes into the batch
+   as a string as soon as it is complete. Nothing collects the slices, and a
+   slice may take up to 3 MiB: past that the split fails
+   while it reads, at the byte the slice starts.
+2. The runtime reads that stream once and stores the batch as it goes; no copy
+   of the file is written and no slice is read back by range.
 3. The activity output is just the batch reference (`{ id, count }`), so the
    parent history stays O(1) whatever the slice count. Per-child results are
    never aggregated: they live with each child run, to be inspected
@@ -222,8 +223,7 @@ await split(file, workflow, {
   every: 10_000, // cut only every N occurrences (groups records)
   trim: { start: 241, end: 241 }, // bytes cut off each end before scanning
   skipEmpty: false, // keep zero-length slices (default: skipped)
-  encoding: 'latin1', // delimiter bytes + slice hydration (default: utf8)
-  inlineMaxBytes: 16_384, // slices up to this size travel as strings (default: 16 KiB)
+  encoding: 'latin1', // delimiter bytes + slice decoding (default: utf8)
   timeoutInMs: 3_600_000, // max ms to await the batch; rejects on expiry
 })
 ```
@@ -254,18 +254,9 @@ await split(file, workflow, {
   workflows. Turn it off when the slice index must align 1:1 with the record
   position in the source file. "Empty" means zero bytes: a whitespace-only
   line is a regular slice.
-- **`encoding`** converts the delimiter to bytes and tells the runtime how to
-  hydrate each slice for the child. Offsets are always computed over raw
-  bytes, so multi-byte encodings never skew the ranges.
-- **`inlineMaxBytes`** (default 16 KiB) is the size up to which a slice is
-  handed to the child as a string, straight from the scan. A slice above it is
-  handed as a reference to its byte range in the durable copy, read back
-  where the child runs. A line of a CSV is a few hundred bytes: reading it
-  back would cost a row lookup and a ranged object read per child, and that,
-  not the scan, is what a million-line split spends its CPU on. Set it to `0`
-  to hand every slice by range. Keep it well under the fan-out message budget
-  of the runtime (`WORKFLOW_BATCH_FANOUT_CHUNK_MAX_BYTES`, 1 MiB by default):
-  an inline slice that does not fit a message is refused.
+- **`encoding`** converts the delimiter to bytes and decodes each slice into
+  the string its child receives. Offsets are always computed over raw bytes,
+  so multi-byte encodings never skew the cuts.
 - **`timeoutInMs`** is the maximum time in milliseconds to await the batch. On
   expiry the activity rejects (reason `timeout`) instead of suspending
   forever — the safety net for a child that never reaches a terminal state.
@@ -374,21 +365,3 @@ already hydrated one at a time — the query compiles once and adds one
 predicate call per entry, no extra serialization and no change to the memory
 profile. It is applied app-side: every child output is still fetched and
 parsed; `where` decides what enters the file, not what leaves the database.
-
-### ByteDelimiterScanner
-
-The scanner behind `split` is exported for direct use. It is a pass-through
-`Transform`: chunks flow through unchanged (so the same pass can persist the
-file) while it records slice offsets in absolute byte positions, handling
-delimiters split across chunk boundaries. `ranges` is complete once the stream
-has flushed.
-
-```typescript
-import { ByteDelimiterScanner } from '@t4h.framework/fs'
-
-const scanner = new ByteDelimiterScanner({ delimiter: { value: '\n' } })
-
-await pipeline(source, scanner, destination)
-
-scanner.slices // [{ start: 0, end: 3, content: <Buffer> }, ...]
-```

package/dist/activities/FileJoinActivity.d.ts

@@ -26,15 +26,15 @@ export type FileJoinActivityInput = {
     options: FileJoinOptions;
     filter?: WorkflowBatchFilter;
 };
-export declare class FileJoinActivity extends SyncActivity<readonly [batch: WorkflowBatchCollectionRef<any>, options: FileJoinOptions], FileJoinActivityInput, Binary, Binary> {
+export declare class FileJoinActivity extends SyncActivity<readonly [batch: WorkflowBatchCollectionRef, options: FileJoinOptions], FileJoinActivityInput, Binary, Binary> {
     private readonly claims;
-    toInput(batch: WorkflowBatchCollectionRef<any>, options: FileJoinOptions): FileJoinActivityInput;
+    toInput(batch: WorkflowBatchCollectionRef, options: FileJoinOptions): FileJoinActivityInput;
     run({ batch, options, filter, }: FileJoinActivityInput): Promise<Binary>;
     toOutput(output: Binary): Binary;
     private toStatus;
     private writeHeader;
     private toLine;
 }
-export declare function join<TOutput = unknown>(batch: WorkflowBatchCollectionRef<any>, options: FileJoinOptions<TOutput>): Promise<Binary>;
+export declare function join<TOutput = unknown>(batch: WorkflowBatchCollectionRef, options: FileJoinOptions<TOutput>): Promise<Binary>;
 export {};
 //# sourceMappingURL=FileJoinActivity.d.ts.map

package/dist/activities/FileJoinActivity.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"FileJoinActivity.d.ts","sourceRoot":"","sources":["../../src/activities/FileJoinActivity.ts"],"names":[],"mappings":"AAGA,OAAO,EACL,KAAK,MAAM,EAGX,YAAY,EAEZ,KAAK,0BAA0B,EAC/B,KAAK,mBAAmB,EAGxB,KAAK,mBAAmB,EACxB,KAAK,kBAAkB,EACxB,MAAM,qBAAqB,CAAA;AAG5B,OAAO,EAAE,GAAG,EAAE,MAAM,mBAAmB,CAAA;AAEvC,MAAM,MAAM,cAAc,GAAG,mBAAmB,CAAA;AAEhD,MAAM,MAAM,aAAa,CAAC,OAAO,GAAG,OAAO,IAAI,kBAAkB,CAAC,OAAO,CAAC,CAAA;AAE1E,KAAK,mBAAmB,CAAC,OAAO,IAAI;IAClC,MAAM,CAAC,EAAE,cAAc,EAAE,CAAA;IACzB,KAAK,CAAC,EAAE,aAAa,CAAC,OAAO,CAAC,CAAA;CAC/B,CAAA;AAED,KAAK,oBAAoB,CAAC,OAAO,IAAI,mBAAmB,CAAC,OAAO,CAAC,GAAG;IAClE,MAAM,EAAE,OAAO,CAAA;IACf,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,SAAS,CAAC,EAAE,MAAM,CAAA;CACnB,CAAA;AAED,KAAK,sBAAsB,CAAC,OAAO,IAAI,mBAAmB,CAAC,OAAO,CAAC,GAAG;IACpE,MAAM,EAAE,SAAS,CAAA;CAClB,CAAA;AAED,KAAK,kBAAkB,CAAC,OAAO,IAAI,mBAAmB,CAAC,OAAO,CAAC,GAAG;IAChE,MAAM,EAAE,KAAK,CAAA;IACb,OAAO,EAAE,GAAG,CAAC,MAAM,EAAE,CAAA;IACrB,SAAS,CAAC,EAAE,MAAM,CAAA;IAClB,MAAM,CAAC,EAAE,OAAO,CAAA;CACjB,CAAA;AAED,MAAM,MAAM,eAAe,CAAC,OAAO,GAAG,OAAO,IACzC,oBAAoB,CAAC,OAAO,CAAC,GAC7B,sBAAsB,CAAC,OAAO,CAAC,GAC/B,kBAAkB,CAAC,OAAO,CAAC,CAAA;AAE/B,MAAM,MAAM,qBAAqB,GAAG;IAClC,KAAK,EAAE,MAAM,CAAA;IACb,OAAO,EAAE,eAAe,CAAA;IACxB,MAAM,CAAC,EAAE,mBAAmB,CAAA;CAC7B,CAAA;AAQD,qBAAa,gBAAiB,SAAQ,YAAY,CAChD,SAAS,CAAC,KAAK,EAAE,0BAA0B,CAAC,GAAG,CAAC,EAAE,OAAO,EAAE,eAAe,CAAC,EAC3E,qBAAqB,EACrB,MAAM,EACN,MAAM,CACP;IACC,OAAO,CAAC,QAAQ,CAAC,MAAM,CAGrB;IAEK,OAAO,CACZ,KAAK,EAAE,0BAA0B,CAAC,GAAG,CAAC,EACtC,OAAO,EAAE,eAAe,GACvB,qBAAqB;IAkBX,GAAG,CAAC,EACf,KAAK,EACL,OAAO,EACP,MAAM,GACP,EAAE,qBAAqB,GAAG,OAAO,CAAC,MAAM,CAAC;IA6BnC,QAAQ,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM;IAIvC,OAAO,CAAC,QAAQ;YAaF,WAAW;IAazB,OAAO,CAAC,MAAM;CAef;AAED,wBAAsB,IAAI,CAAC,OAAO,GAAG,OAAO,EAC1C,KAAK,EAAE,0BAA0B,CAAC,GAAG,CAAC,EACtC,OAAO,EAAE,eAAe,CAAC,OAAO,CAAC,GAChC,OAAO,CAAC,MAAM,CAAC,CAMjB"}
+{"version":3,"file":"FileJoinActivity.d.ts","sourceRoot":"","sources":["../../src/activities/FileJoinActivity.ts"],"names":[],"mappings":"AAGA,OAAO,EACL,KAAK,MAAM,EAGX,YAAY,EAEZ,KAAK,0BAA0B,EAC/B,KAAK,mBAAmB,EAGxB,KAAK,mBAAmB,EACxB,KAAK,kBAAkB,EACxB,MAAM,qBAAqB,CAAA;AAG5B,OAAO,EAAE,GAAG,EAAE,MAAM,mBAAmB,CAAA;AAEvC,MAAM,MAAM,cAAc,GAAG,mBAAmB,CAAA;AAEhD,MAAM,MAAM,aAAa,CAAC,OAAO,GAAG,OAAO,IAAI,kBAAkB,CAAC,OAAO,CAAC,CAAA;AAE1E,KAAK,mBAAmB,CAAC,OAAO,IAAI;IAClC,MAAM,CAAC,EAAE,cAAc,EAAE,CAAA;IACzB,KAAK,CAAC,EAAE,aAAa,CAAC,OAAO,CAAC,CAAA;CAC/B,CAAA;AAED,KAAK,oBAAoB,CAAC,OAAO,IAAI,mBAAmB,CAAC,OAAO,CAAC,GAAG;IAClE,MAAM,EAAE,OAAO,CAAA;IACf,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,SAAS,CAAC,EAAE,MAAM,CAAA;CACnB,CAAA;AAED,KAAK,sBAAsB,CAAC,OAAO,IAAI,mBAAmB,CAAC,OAAO,CAAC,GAAG;IACpE,MAAM,EAAE,SAAS,CAAA;CAClB,CAAA;AAED,KAAK,kBAAkB,CAAC,OAAO,IAAI,mBAAmB,CAAC,OAAO,CAAC,GAAG;IAChE,MAAM,EAAE,KAAK,CAAA;IACb,OAAO,EAAE,GAAG,CAAC,MAAM,EAAE,CAAA;IACrB,SAAS,CAAC,EAAE,MAAM,CAAA;IAClB,MAAM,CAAC,EAAE,OAAO,CAAA;CACjB,CAAA;AAED,MAAM,MAAM,eAAe,CAAC,OAAO,GAAG,OAAO,IACzC,oBAAoB,CAAC,OAAO,CAAC,GAC7B,sBAAsB,CAAC,OAAO,CAAC,GAC/B,kBAAkB,CAAC,OAAO,CAAC,CAAA;AAE/B,MAAM,MAAM,qBAAqB,GAAG;IAClC,KAAK,EAAE,MAAM,CAAA;IACb,OAAO,EAAE,eAAe,CAAA;IACxB,MAAM,CAAC,EAAE,mBAAmB,CAAA;CAC7B,CAAA;AAQD,qBAAa,gBAAiB,SAAQ,YAAY,CAChD,SAAS,CAAC,KAAK,EAAE,0BAA0B,EAAE,OAAO,EAAE,eAAe,CAAC,EACtE,qBAAqB,EACrB,MAAM,EACN,MAAM,CACP;IACC,OAAO,CAAC,QAAQ,CAAC,MAAM,CAGrB;IAEK,OAAO,CACZ,KAAK,EAAE,0BAA0B,EACjC,OAAO,EAAE,eAAe,GACvB,qBAAqB;IAkBX,GAAG,CAAC,EACf,KAAK,EACL,OAAO,EACP,MAAM,GACP,EAAE,qBAAqB,GAAG,OAAO,CAAC,MAAM,CAAC;IA6BnC,QAAQ,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM;IAIvC,OAAO,CAAC,QAAQ;YAaF,WAAW;IAazB,OAAO,CAAC,MAAM;CAef;AAED,wBAAsB,IAAI,CAAC,OAAO,GAAG,OAAO,EAC1C,KAAK,EAAE,0BAA0B,EACjC,OAAO,EAAE,eAAe,CAAC,OAAO,CAAC,GAChC,OAAO,CAAC,MAAM,CAAC,CAMjB"}

package/dist/activities/FileJoinActivity.js.map

@@ -1 +1 @@
-{"version":3,"file":"FileJoinActivity.js","sourceRoot":"","sources":["../../src/activities/FileJoinActivity.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,aAAa,CAAA;AAClC,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAA;AAEzC,OAAO,EAEL,KAAK,EACL,OAAO,EACP,YAAY,EACZ,kBAAkB,EAIlB,kBAAkB,GAGnB,MAAM,qBAAqB,CAAA;AAE5B,OAAO,EAAE,eAAe,EAAE,MAAM,uBAAuB,CAAA;AACvD,OAAO,EAAE,GAAG,EAAE,MAAM,mBAAmB,CAAA;AAuCvC,MAAM,UAAU,GAA8C;IAC5D,KAAK,EAAE,KAAK;IACZ,OAAO,EAAE,QAAQ;IACjB,GAAG,EAAE,KAAK;CACX,CAAA;AAED,MAAM,OAAO,gBAAiB,SAAQ,YAKrC;IACkB,MAAM,GAAG,IAAI,KAAK,CAAC;QAClC,EAAE,EAAE,eAAe;QACnB,KAAK,EAAE,kBAAkB;KAC1B,CAAC,CAAA;IAEK,OAAO,CACZ,KAAsC,EACtC,OAAwB;QAExB,IAAI,OAAO,CAAC,KAAK;YACf,kBAAkB,CAAC,kBAAkB,CACnC,OAAO,CAAC,KAAK,EACb,OAAO,EACP,YAAY,CACb,CAAA;QAEH,MAAM,MAAM,GAAwB;YAClC,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,KAAK,EAAE,KAAK,CAAC,KAAK;SACnB,CAAA;QAED,IAAI,CAAC,MAAM,CAAC,MAAM,IAAI,CAAC,MAAM,CAAC,KAAK;YAAE,OAAO,EAAE,KAAK,EAAE,KAAK,CAAC,EAAE,EAAE,OAAO,EAAE,CAAA;QAExE,OAAO,EAAE,KAAK,EAAE,KAAK,CAAC,EAAE,EAAE,OAAO,EAAE,MAAM,EAAE,CAAA;IAC7C,CAAC;IAEM,KAAK,CAAC,GAAG,CAAC,EACf,KAAK,EACL,OAAO,EACP,MAAM,GACgB;QACtB,MAAM,MAAM,GAAG,IAAI,WAAW,EAAE,CAAA;QAEhC,MAAM,OAAO,GAAG,IAAI,CAAC,MAAM,CAAC,EAAE,CAAC,KAAK,CAClC,QAAQ,IAAI,CAAC,EAAE,IAAI,UAAU,CAAC,OAAO,CAAC,MAAM,CAAC,EAAE,EAC/C,MAAM,CACP,CAAA;QAED,MAAM,KAAK,GAAG,KAAK,EAAE,IAAY,EAAE,EAAE;YACnC,IAAI,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC;gBAAE,MAAM,IAAI,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;QACtD,CAAC,CAAA;QAED,MAAM,OAAO,GAAG,kBAAkB,CAAC,MAAM,CACvC,IAAI,CAAC,MAAM,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,EAChC,kBAAkB,CAAC,KAAK,CAAC,MAAM,EAAE;YAC/B,MAAM,EAAE,IAAI,CAAC,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;YACtC,KAAK,EAAE,OAAO,CAAC,KAAK;SACrB,CAAC,CACH,CAAA;QAED,MAAM,IAAI,CAAC,WAAW,CAAC,OAAO,EAAE,KAAK,CAAC,CAAA;QAEtC,IAAI,KAAK,EAAE,MAAM,KAAK,IAAI,OAAO;YAAE,MAAM,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,KAAK,EAAE,OAAO,CAAC,CAAC,CAAA;QAE3E,MAAM,CAAC,GAAG,EAAE,CAAA;QAEZ,OAAO,MAAM,OAAO,CAAA;IACtB,CAAC;IAEM,QAAQ,CAAC,MAAc;QAC5B,OAAO,MAAM,CAAA;IACf,CAAC;IAEO,QAAQ,CACd,OAAwB,EACxB,MAA4B;QAE5B,IAAI,OAAO,CAAC,MAAM;YAAE,OAAO,OAAO,CAAC,MAAM,CAAA;QAEzC,IAAI,MAAM,EAAE,MAAM;YAAE,OAAM;QAE1B,IAAI,OAAO,CAAC,MAAM,KAAK,SAAS;YAAE,OAAO,CAAC,WAAW,EAAE,UAAU,CAAC,CAAA;QAElE,OAAO,CAAC,WAAW,CAAC,CAAA;IACtB,CAAC;IAEO,KAAK,CAAC,WAAW,CACvB,OAAwB,EACxB,KAAsC;QAEtC,IAAI,OAAO,CAAC,MAAM,KAAK,OAAO,IAAI,OAAO,CAAC,MAAM;YAC9C,MAAM,KAAK,CAAC,OAAO,CAAC,MAAM,GAAG,CAAC,OAAO,CAAC,SAAS,IAAI,IAAI,CAAC,CAAC,CAAA;QAE3D,IAAI,OAAO,CAAC,MAAM,KAAK,KAAK,IAAI,OAAO,CAAC,MAAM,KAAK,KAAK;YACtD,MAAM,KAAK,CACT,GAAG,CAAC,QAAQ,CAAC,OAAO,CAAC,OAAO,EAAE,EAAE,SAAS,EAAE,OAAO,CAAC,SAAS,EAAE,CAAC,CAChE,CAAA;IACL,CAAC;IAEO,MAAM,CAAC,KAA0B,EAAE,OAAwB;QACjE,IAAI,OAAO,CAAC,MAAM,KAAK,SAAS;YAAE,OAAO,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,GAAG,IAAI,CAAA;QAErE,IAAI,OAAO,CAAC,MAAM,KAAK,KAAK;YAC1B,OAAO,GAAG,CAAC,MAAM,CAAC,KAAK,CAAC,MAAM,EAAE,OAAO,CAAC,OAAO,EAAE;gBAC/C,SAAS,EAAE,OAAO,CAAC,SAAS;aAC7B,CAAC,CAAA;QAEJ,MAAM,KAAK,GACT,OAAO,KAAK,CAAC,MAAM,KAAK,QAAQ;YAC9B,CAAC,CAAC,KAAK,CAAC,MAAM;YACd,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,MAAM,CAAC,CAAA;QAElC,OAAO,KAAK,GAAG,CAAC,OAAO,CAAC,SAAS,IAAI,IAAI,CAAC,CAAA;IAC5C,CAAC;CACF;AAED,MAAM,CAAC,KAAK,UAAU,IAAI,CACxB,KAAsC,EACtC,OAAiC;IAEjC,OAAO,MAAM,OAAO,CAAC,UAAU,CAC7B,gBAAgB,EAChB,KAAK,EACL,OAA0B,CAC3B,CAAA;AACH,CAAC"}
+{"version":3,"file":"FileJoinActivity.js","sourceRoot":"","sources":["../../src/activities/FileJoinActivity.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,aAAa,CAAA;AAClC,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAA;AAEzC,OAAO,EAEL,KAAK,EACL,OAAO,EACP,YAAY,EACZ,kBAAkB,EAIlB,kBAAkB,GAGnB,MAAM,qBAAqB,CAAA;AAE5B,OAAO,EAAE,eAAe,EAAE,MAAM,uBAAuB,CAAA;AACvD,OAAO,EAAE,GAAG,EAAE,MAAM,mBAAmB,CAAA;AAuCvC,MAAM,UAAU,GAA8C;IAC5D,KAAK,EAAE,KAAK;IACZ,OAAO,EAAE,QAAQ;IACjB,GAAG,EAAE,KAAK;CACX,CAAA;AAED,MAAM,OAAO,gBAAiB,SAAQ,YAKrC;IACkB,MAAM,GAAG,IAAI,KAAK,CAAC;QAClC,EAAE,EAAE,eAAe;QACnB,KAAK,EAAE,kBAAkB;KAC1B,CAAC,CAAA;IAEK,OAAO,CACZ,KAAiC,EACjC,OAAwB;QAExB,IAAI,OAAO,CAAC,KAAK;YACf,kBAAkB,CAAC,kBAAkB,CACnC,OAAO,CAAC,KAAK,EACb,OAAO,EACP,YAAY,CACb,CAAA;QAEH,MAAM,MAAM,GAAwB;YAClC,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,KAAK,EAAE,KAAK,CAAC,KAAK;SACnB,CAAA;QAED,IAAI,CAAC,MAAM,CAAC,MAAM,IAAI,CAAC,MAAM,CAAC,KAAK;YAAE,OAAO,EAAE,KAAK,EAAE,KAAK,CAAC,EAAE,EAAE,OAAO,EAAE,CAAA;QAExE,OAAO,EAAE,KAAK,EAAE,KAAK,CAAC,EAAE,EAAE,OAAO,EAAE,MAAM,EAAE,CAAA;IAC7C,CAAC;IAEM,KAAK,CAAC,GAAG,CAAC,EACf,KAAK,EACL,OAAO,EACP,MAAM,GACgB;QACtB,MAAM,MAAM,GAAG,IAAI,WAAW,EAAE,CAAA;QAEhC,MAAM,OAAO,GAAG,IAAI,CAAC,MAAM,CAAC,EAAE,CAAC,KAAK,CAClC,QAAQ,IAAI,CAAC,EAAE,IAAI,UAAU,CAAC,OAAO,CAAC,MAAM,CAAC,EAAE,EAC/C,MAAM,CACP,CAAA;QAED,MAAM,KAAK,GAAG,KAAK,EAAE,IAAY,EAAE,EAAE;YACnC,IAAI,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC;gBAAE,MAAM,IAAI,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;QACtD,CAAC,CAAA;QAED,MAAM,OAAO,GAAG,kBAAkB,CAAC,MAAM,CACvC,IAAI,CAAC,MAAM,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,EAChC,kBAAkB,CAAC,KAAK,CAAC,MAAM,EAAE;YAC/B,MAAM,EAAE,IAAI,CAAC,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;YACtC,KAAK,EAAE,OAAO,CAAC,KAAK;SACrB,CAAC,CACH,CAAA;QAED,MAAM,IAAI,CAAC,WAAW,CAAC,OAAO,EAAE,KAAK,CAAC,CAAA;QAEtC,IAAI,KAAK,EAAE,MAAM,KAAK,IAAI,OAAO;YAAE,MAAM,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,KAAK,EAAE,OAAO,CAAC,CAAC,CAAA;QAE3E,MAAM,CAAC,GAAG,EAAE,CAAA;QAEZ,OAAO,MAAM,OAAO,CAAA;IACtB,CAAC;IAEM,QAAQ,CAAC,MAAc;QAC5B,OAAO,MAAM,CAAA;IACf,CAAC;IAEO,QAAQ,CACd,OAAwB,EACxB,MAA4B;QAE5B,IAAI,OAAO,CAAC,MAAM;YAAE,OAAO,OAAO,CAAC,MAAM,CAAA;QAEzC,IAAI,MAAM,EAAE,MAAM;YAAE,OAAM;QAE1B,IAAI,OAAO,CAAC,MAAM,KAAK,SAAS;YAAE,OAAO,CAAC,WAAW,EAAE,UAAU,CAAC,CAAA;QAElE,OAAO,CAAC,WAAW,CAAC,CAAA;IACtB,CAAC;IAEO,KAAK,CAAC,WAAW,CACvB,OAAwB,EACxB,KAAsC;QAEtC,IAAI,OAAO,CAAC,MAAM,KAAK,OAAO,IAAI,OAAO,CAAC,MAAM;YAC9C,MAAM,KAAK,CAAC,OAAO,CAAC,MAAM,GAAG,CAAC,OAAO,CAAC,SAAS,IAAI,IAAI,CAAC,CAAC,CAAA;QAE3D,IAAI,OAAO,CAAC,MAAM,KAAK,KAAK,IAAI,OAAO,CAAC,MAAM,KAAK,KAAK;YACtD,MAAM,KAAK,CACT,GAAG,CAAC,QAAQ,CAAC,OAAO,CAAC,OAAO,EAAE,EAAE,SAAS,EAAE,OAAO,CAAC,SAAS,EAAE,CAAC,CAChE,CAAA;IACL,CAAC;IAEO,MAAM,CAAC,KAA0B,EAAE,OAAwB;QACjE,IAAI,OAAO,CAAC,MAAM,KAAK,SAAS;YAAE,OAAO,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,GAAG,IAAI,CAAA;QAErE,IAAI,OAAO,CAAC,MAAM,KAAK,KAAK;YAC1B,OAAO,GAAG,CAAC,MAAM,CAAC,KAAK,CAAC,MAAM,EAAE,OAAO,CAAC,OAAO,EAAE;gBAC/C,SAAS,EAAE,OAAO,CAAC,SAAS;aAC7B,CAAC,CAAA;QAEJ,MAAM,KAAK,GACT,OAAO,KAAK,CAAC,MAAM,KAAK,QAAQ;YAC9B,CAAC,CAAC,KAAK,CAAC,MAAM;YACd,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,MAAM,CAAC,CAAA;QAElC,OAAO,KAAK,GAAG,CAAC,OAAO,CAAC,SAAS,IAAI,IAAI,CAAC,CAAA;IAC5C,CAAC;CACF;AAED,MAAM,CAAC,KAAK,UAAU,IAAI,CACxB,KAAiC,EACjC,OAAiC;IAEjC,OAAO,MAAM,OAAO,CAAC,UAAU,CAC7B,gBAAgB,EAChB,KAAK,EACL,OAA0B,CAC3B,CAAA;AACH,CAAC"}

package/dist/activities/FileReadActivity.d.ts

@@ -17,6 +17,7 @@ export declare class FileReadActivity extends SyncActivity<readonly [binary: Bin
     toOutput(output: string): string;
     private slice;
     private window;
+    private collect;
 }
 export declare function read(binary: Binary, options?: FileReadOptions): Promise<string>;
 //# sourceMappingURL=FileReadActivity.d.ts.map

package/dist/activities/FileReadActivity.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"FileReadActivity.d.ts","sourceRoot":"","sources":["../../src/activities/FileReadActivity.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,KAAK,MAAM,EAAkB,YAAY,EAAE,MAAM,qBAAqB,CAAA;AAI/E,MAAM,MAAM,eAAe,GAAG;IAC5B,KAAK,CAAC,EAAE;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,GAAG,EAAE,MAAM,CAAA;KAAE,CAAA;IACtC,QAAQ,CAAC,EAAE,cAAc,CAAA;CAC1B,CAAA;AAED,MAAM,MAAM,qBAAqB,GAAG;IAClC,MAAM,EAAE,MAAM,CAAA;IACd,OAAO,EAAE,eAAe,CAAA;CACzB,CAAA;AAID,qBAAa,gBAAiB,SAAQ,YAAY,CAChD,SAAS,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,eAAe,CAAC,EACnD,qBAAqB,EACrB,MAAM,EACN,MAAM,CACP;IACC,OAAO,CAAC,QAAQ,CAAC,MAAM,CAErB;IAEK,OAAO,CACZ,MAAM,EAAE,MAAM,EACd,OAAO,EAAE,eAAe,GACvB,qBAAqB;IAIX,GAAG,CAAC,EACf,MAAM,EACN,OAAO,GACR,EAAE,qBAAqB,GAAG,OAAO,CAAC,MAAM,CAAC;IAyBnC,QAAQ,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM;YAIzB,KAAK;YAYL,MAAM;CAuCrB;AAED,wBAAsB,IAAI,CACxB,MAAM,EAAE,MAAM,EACd,OAAO,GAAE,eAAoB,GAC5B,OAAO,CAAC,MAAM,CAAC,CAEjB"}
+{"version":3,"file":"FileReadActivity.d.ts","sourceRoot":"","sources":["../../src/activities/FileReadActivity.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,KAAK,MAAM,EAAkB,YAAY,EAAE,MAAM,qBAAqB,CAAA;AAI/E,MAAM,MAAM,eAAe,GAAG;IAC5B,KAAK,CAAC,EAAE;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,GAAG,EAAE,MAAM,CAAA;KAAE,CAAA;IACtC,QAAQ,CAAC,EAAE,cAAc,CAAA;CAC1B,CAAA;AAED,MAAM,MAAM,qBAAqB,GAAG;IAClC,MAAM,EAAE,MAAM,CAAA;IACd,OAAO,EAAE,eAAe,CAAA;CACzB,CAAA;AAID,qBAAa,gBAAiB,SAAQ,YAAY,CAChD,SAAS,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,eAAe,CAAC,EACnD,qBAAqB,EACrB,MAAM,EACN,MAAM,CACP;IACC,OAAO,CAAC,QAAQ,CAAC,MAAM,CAErB;IAEK,OAAO,CACZ,MAAM,EAAE,MAAM,EACd,OAAO,EAAE,eAAe,GACvB,qBAAqB;IAIX,GAAG,CAAC,EACf,MAAM,EACN,OAAO,GACR,EAAE,qBAAqB,GAAG,OAAO,CAAC,MAAM,CAAC;IAyBnC,QAAQ,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM;YAIzB,KAAK;YAYL,MAAM;YAoBN,OAAO;CA8BtB;AAED,wBAAsB,IAAI,CACxB,MAAM,EAAE,MAAM,EACd,OAAO,GAAE,eAAoB,GAC5B,OAAO,CAAC,MAAM,CAAC,CAEjB"}