mirror of
https://github.com/openprose/prose.git
synced 2026-09-19 05:55:05 +08:00
irl-dan
63c8ce4b23
Move the standard library (previously `github.com/openprose/std`) and
the company-as-prose library (previously local dir
`/Users/sl/code/openprose/company-as-prose`) into this repository
under `packages/std/` and `packages/co/` respectively.
Motivation: concentrate attention on one repository so stars,
discussions, and issues aggregate. `openprose/std` was a genuinely
useful asset nobody could find because ~50 stars on its own repo
told a much worse story than 1,106 stars on `openprose/prose`
would have. Same logic applies to co.
Layout choice: `packages/{std,co}/` rather than `std/` + `co/` at
the repo root. Root siblings accumulate over time, and a flat
top-level made future libraries (hub, kit, dev, etc.) compete with
spec infrastructure. `packages/` is bounded — new libraries land
there without cluttering root. Matches pnpm/Deno/monorepo tooling
conventions.
Changes:
- New: `packages/std/` (copied from openprose/std, `.git` excluded)
- New: `packages/co/` (copied from company-as-prose, README updated
for new name and location)
- `packages/std/README.md`: updated shorthand expansion reference
- `packages/co/README.md`: renamed "company-as-prose" to "co" in
self-references, added std-vs-co split heuristic, updated
`prose run` examples to use `co/` shorthand
- `skills/open-prose/deps.md`:
- `std/` shorthand now expands to
`github.com/openprose/prose/packages/std/`
- `co/` shorthand added, expands to
`github.com/openprose/prose/packages/co/`
- Both shorthands resolve into the same clone of
`openprose/prose` under `.deps/github.com/openprose/prose/`;
`packages/std/` and `packages/co/` are sibling subdirectories
- `prose.lock` format row updated to `host/owner/repo sha`
(matches the explicit-host resolution that landed in #35)
- `.deps/` directory structure example redrawn to show the
`{host}/{owner}/{repo}/packages/{std,co}/...` shape
- Error message and Interaction tables refreshed accordingly
- Resolution Algorithm step 1 now documents both shorthands
- `skills/open-prose/forme.md`: Step 2 resolution list updated to
include co/ shorthand and the host-keyed `.deps/` layout
- `skills/open-prose/help.md`: Q&A "How do dependencies work?"
rewritten to name both shorthands and the new explicit-host model
- `skills/open-prose/state/filesystem.md`: `.deps/` directory
tree re-drawn to include the `{host}/` layer with std/co as
sibling packages inside the clone
- `skills/open-prose/guidance/patterns.md`,
`skills/open-prose/guidance/antipatterns.md`: examples now use
the `std/` shorthand or explicit `github.com/...` rather than
the deprecated bare `openprose/std/` form
- `skills/open-prose/examples/registry-import/index.md`: sample
service reference switched to `std/evals/inspector`
- `README.md`: Stdlib badge replaced with internal `packages/std/`
link plus new `packages/co/` link; "Standard Library" section
rewritten as "Libraries" with both packages described
Out of scope for this PR (deliberately):
- Tooling changes to `prose install` and Forme's `.deps/` writer
to adopt the `{host}/{owner}/{repo}/` layout in practice — this
PR is spec-only. Existing tooling continues to work against
whatever layout it currently implements; the spec now describes
the target.
- Retiring the `openprose/std` GitHub repo. Delete that repo
separately after this merges.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.3 KiB
2.3 KiB
name, kind
| name | kind |
|---|---|
| formatter | service |
Formatter
Transform structured data into a specified output format -- Markdown, JSON, HTML, CSV, plain text, or any other target. Use formatter as the last mile of a pipeline, converting internal data structures into the presentation format the consumer needs. Distinct from extractor (which lifts structure from unstructured input) and writer (which creates new content) -- formatter reshapes existing structured data without adding or removing information.
Description
Transform structured data into a specified output format with no information loss.
Metadata
version: 0.1.0
Requires
- data: the structured input to format
- target_format: the desired output format (e.g., Markdown, JSON, HTML, CSV) with any style or layout requirements
Ensures
- formatted: the data rendered in the target format where:
- all information from the input is present in the output -- no fields dropped silently
- the output is valid in the target format (valid JSON parses, valid HTML renders, valid CSV has consistent columns)
- missing or null fields are handled gracefully (omitted with a note, rendered as empty, or replaced with a placeholder -- consistent throughout)
Errors
- unsupported-format: the target format is not recognized or cannot represent the input data
- data-unstructured: the input data has no discernible structure to format
Strategies
- when the data has nested structures: flatten or indent according to the target format's conventions, preserving hierarchy
- when fields are missing: use a consistent strategy throughout (do not omit some nulls and placeholder others)
- when the target format has length limits: truncate content fields before metadata fields, and indicate truncation
- when multiple layout options exist: prefer the layout that makes the data scannable (tables over paragraphs for tabular data, lists over prose for enumerations)
Notes
Formatter is a shape-preserving transformation. It does not analyze, summarize, or create -- it presents. For lifting structured data from unstructured input, use extractor. For compressing content, use summarizer. For creating new written content, use writer. Formatter is the role that makes output consumable by its final audience, whether that audience is a human reading Markdown or a system parsing JSON.