Merge commit 'f8782ee4bb70e8a916bed24c11e9389c28e58481' as 'repos/effect'

Author: samuelho-dev

repos/effect/.agents/skills/grill-me/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: grill-me
+description: Interview the user about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+---
+
+Interview me about every aspect of this plan until we reach a shared understanding and a defensible design.
+
+Ask exactly one question at a time, then wait for my answer before asking the next question.
+
+Use each answer to choose the next highest-leverage unresolved question. Maintain an implicit decision tree of resolved decisions, open questions, assumptions, dependencies, risks, and rejected alternatives.
+
+For each question, include:
+
+- clear answer options when appropriate
+- your recommended answer, marked as recommended
+- a brief reason for the recommendation
+
+Use open-ended questions when fixed options would prematurely constrain the design space.
+
+Challenge vague, inconsistent, risky, or unsupported assumptions. If an answer creates a contradiction or unresolved dependency, ask a follow-up before moving on.
+
+Cover, as relevant:
+
+- goals and non-goals
+- users and stakeholders
+- constraints
+- alternatives
+- APIs and interfaces
+- data model
+- error handling
+- security
+- observability
+- testing
+- migration and rollout
+- failure modes
+- operational ownership
+- success criteria
+
+If repository facts are needed, inspect the codebase instead of asking the user. Do not ask me to provide information that can be determined locally.
+
+When an available user-input tool such as `request_user_input` fits the question, use it to ask one short question with a small set of mutually exclusive options. Otherwise, ask in plain text and present clear possible answers as a numbered list when that helps me answer quickly. Include your recommended option and mark it as recommended.
+
+Stop when the major branches of the design tree have been resolved. Then summarize the agreed design, remaining risks, assumptions, rejected alternatives, and next steps.

repos/effect/.agents/skills/standard-jsdoc/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: standard-jsdoc
+description: Write, insert, or update Effect public API JSDoc so it satisfies the standard-jsdoc oxlint rule. Use when adding or fixing JSDoc comments, resolving standard-jsdoc diagnostics, preparing docs for JSON extraction, or reviewing public API documentation.
+---
+
+Use this skill to write well-formed JSDoc for Effect public APIs.
+
+## Required documentation shape
+
+Use a normal multiline JSDoc comment in TypeScript source:
+
+```ts
+/**
+ * Short description as one paragraph.
+ *
+ * **When to use**
+ *
+ * Optional practical usage guidance.
+ *
+ * **Details**
+ *
+ * Optional details for complex APIs, options, overloads, or behavior.
+ *
+ * **Gotchas**
+ *
+ * Optional edge cases, footguns, or surprising behavior.
+ *
+ * **Example** (Short title)
+ *
+ * Optional prose explaining the example.
+ *
+ * ```ts
+ * const result = example()
+ * ```
+ *
+ * @category constructors
+ * @since 1.0.0
+ */
+```
+
+## Writing rules
+
+- Use sober, practical prose.
+- Do not use jargon when a plain word works.
+- Do not be clever.
+- Do not add filler sections.
+- The short description is required and must be exactly one paragraph.
+- Optional sections must appear in this order:
+  1. `**When to use**`
+  2. `**Details**`
+  3. `**Gotchas**`
+- Include an optional section only when it has useful, non-empty content.
+- `**When to use**` is important when the API has close alternatives, trade-offs, or `@see` tags. If `@see` tags are present, inspect the referenced APIs and add `**When to use**` when it helps readers choose between them.
+- Add `@see` only for APIs that are similar to the documented API but intended for different situations or usage patterns. Do not add `@see` for loosely related helpers, dependencies, implementation details, or general background links.
+- Before deciding whether to include `**Gotchas**`, inspect the implementation and nearby tests for edge cases, footguns, preconditions, surprising behavior, or important failure modes. Add `**Gotchas**` only when you find a real gotcha worth documenting.
+- Use exactly one blank line between the short description, sections, examples, and tags.
+- Do not use Markdown headings such as `# Heading` or ad hoc bold headings such as `**Notes**`; only the standard headings are allowed.
+- Examples must use `**Example** (Title)`, optional prose, and exactly one non-empty `ts` code fence.
+- Example titles must be unique after trimming and lowercasing.
+- Do not use `@example`.
+- Do not put TypeScript code fences outside `**Example** (Title)` sections.
+- Inline `{@link Symbol}` targets must resolve to TypeScript symbols; do not link to URLs with `{@link}`.
+- Do not document module-level comments; module JSDoc is ignored by this rule.
+- `@internal` means the item is ignored; do not rewrite it as public docs.
+- Default exports are ignored by this rule and do not need JSDoc.
+- Do not add unsupported constructs such as enums or empty exports in checked files.
+
+## Tag rules
+
+When multiple tags are present, keep them in this order:
+
+1. `@deprecated`
+2. `@default`
+3. `@see`
+4. `@category`
+5. `@since`
+
+Root declarations:
+
+- Require `@category`.
+- Require `@since` with stable semver like `1.2.3`.
+- May use `@deprecated` with a non-empty message.
+- May use repeated non-empty `@see` tags, but only for similar APIs with different usage patterns.
+- Must not use `@default`.
+
+Namespaces and declarations inside namespaces:
+
+- Require `@since` with stable semver like `1.2.3`.
+- May use optional `@category`.
+- May use `@deprecated` with a non-empty message.
+- May use repeated non-empty `@see` tags, but only for similar APIs with different usage patterns.
+- Must not use `@default`.
+
+Members:
+
+- JSDoc is optional.
+- When member JSDoc is present, it must follow the same short description, section, example, spacing, and tag-order rules.
+- May use optional `@since` with stable semver like `1.2.3`.
+- May use `@default` with a non-empty value.
+- May use `@deprecated` with a non-empty message.
+- May use repeated non-empty `@see` tags, but only for similar APIs with different usage patterns.
+- Must not use `@category`.
+
+## Updating existing JSDoc
+
+When fixing or updating existing docs:
+
+1. Preserve correct facts and examples.
+2. Rewrite the layout into the standard template.
+3. Move usage guidance into `**When to use**`; when `@see` tags are present, inspect the referenced APIs and explain selection guidance if useful.
+4. Move option, overload, and behavior details into `**Details**`.
+5. Move caveats into `**Gotchas**`; if no caveat is already documented, inspect the implementation and nearby tests before deciding whether a `**Gotchas**` section is warranted.
+6. Convert `@example` tags and loose `ts` fences into `**Example** (Title)` sections.
+7. Preserve valid `@see`, `@deprecated`, `@default`, `@category`, and `@since` tags.
+8. Remove `@see` tags that do not point to similar APIs with meaningfully different usage patterns.
+9. Remove sections that would be empty.
+
+## Validation
+
+After changing JSDoc governed by the rule, run the narrowest relevant validation:
+
+```sh
+pnpm test packages/tools/oxc/test/standard-jsdoc.test.ts
+pnpm check:tsgo
+```
+
+If the changed package has generated docs, also run `pnpm docgen` from that package directory.

repos/effect/.changeset/add-bigdecimal-sumall-multiplyall.md

@@ -0,0 +1,5 @@
+---
+"effect": patch
+---
+
+Added `BigDecimal.sumAll` and `BigDecimal.multiplyAll` for feature parity with `Number` and `BigInt`, closes #1880.

repos/effect/.changeset/add-chunk-schema.md

@@ -0,0 +1,5 @@
+---
+"effect": patch
+---
+
+Schema: add `Chunk` schema, closes #1585.

repos/effect/.changeset/add-command-hidden.md

@@ -0,0 +1,19 @@
+---
+"effect": patch
+---
+
+Add `Command.withHidden` to hide subcommands from `--help` output, shell completions, and "did you mean?" suggestions, while keeping them fully invocable by exact name.
+
+Useful for experimental or internal subcommands that should be accepted but not advertised on the public CLI surface.
+
+```ts
+import { Command } from "effect/unstable/cli"
+
+const experimental = Command.make("experimental").pipe(
+  Command.withHidden
+)
+
+const root = Command.make("mycli").pipe(
+  Command.withSubcommands([experimental])
+)
+```

repos/effect/.changeset/add-config-nested.md

@@ -0,0 +1,5 @@
+---
+"effect": patch
+---
+
+Add `Config.nested` combinator to scope a config under a named prefix, closes #1437.

repos/effect/.changeset/add-flag-hidden.md

@@ -0,0 +1,15 @@
+---
+"effect": patch
+---
+
+Add `Flag.withHidden` (and `Param.withHidden`) to hide flags from `--help` output and shell completions while keeping them fully parseable on the command line.
+
+Useful for experimental, internal, or deprecated flags that should be accepted but not advertised, e.g. `--experimental-foo`, debug toggles, or escape hatches that are not yet committed to the public CLI surface.
+
+```ts
+import { Flag } from "effect/unstable/cli"
+
+const experimental = Flag.boolean("experimental-foo").pipe(
+  Flag.withHidden
+)
+```

repos/effect/.changeset/add-from-string-schemas.md

@@ -0,0 +1,5 @@
+---
+"effect": patch
+---
+
+Add `DateFromString`, `BigIntFromString`, `BigDecimalFromString`, `TimeZoneNamedFromString`, `TimeZoneFromString`, and `DateTimeZonedFromString` schemas, closes #1941.

repos/effect/.changeset/add-headers-remove-many.md

@@ -0,0 +1,5 @@
+---
+"effect": patch
+---
+
+unstable/http Headers: add `removeMany` combinator for removing multiple headers at once

repos/effect/.changeset/add-indexeddb-kvs-layer.md

@@ -0,0 +1,5 @@
+---
+"@effect/platform-browser": patch
+---
+
+Adds an IndexedDB backed implementation of `KeyValueStore` as `BrowserKeyValueStore.layerIndexedDb`. This backend allows for non-blocking `KeyValueStore` operations, unlike the existing `Storage` api backed implementations.