Limits and Next Steps

Limits and Next Steps

The limits of rosetta are narrow and mostly known, which suits a version 0.1.0 tool, and the first of them matters most because it concerns the file the design calls the source of truth. Each limit below was either stated in the README or reproduced in a scratch copy of the example artifact for this wiki.

Limits

Limit	What happens
rosetta sync ignores edits made only to fields.json	The command prints sync: no-op, and the packet and the Markdown keep their old values. In the example, changing DECISION_COUNT from 3 to 7 in the JSON left both views unchanged
Only the PacketSpec kind exists	The ProgramSpec kind in the design notes, which would compile pseudocode to source, is not implemented
Values are strings, integers, and floats	Nested values are not supported, and the notation for them is an open question in the design
Packet values are strings	After a packet sync, numbers are stored as strings in fields.json; validate coerces them back using the schema
Floats are written with two decimals	0.925 becomes RATE=0.93 in the packet while the Markdown keeps 0.925, so the views disagree from the first bootstrap
Markdown bullets are display only	Only the ROSETTA:FIELDS comment is read, so a bullet edited on its own makes sync report human-to-machine while the packet and the fields file keep the old value, and the Markdown keeps the edited bullet until a later packet sync regenerates the block
Agreeing edits still conflict	Two views changed to match each other report CONFLICT: conflicting fields: with no keys listed; restoring one view to its locked content clears it
The loader falls back silently	A consumer cannot tell whether it received the packet or the Markdown
Token savings are not measured	The companion benchmark, rosetta-bench, was built to test the claim, and no results from a real model exist
Run on Windows with Python 3.12 only	The checks for this wiki ran in a Git Bash shell on Windows; Linux and macOS were not tried

Next steps

No dates are attached, and the order follows how much each item reduces the chance of silent loss.

1. Hash fields.json into the lock. A third hash makes the record a view of equal standing, so that an edit to it propagates to both renderings, and the principal limit closes.
2. Compare bullets with the comment. When the generated bullets and the embedded fields disagree, fail with the keys and the line, instead of letting one overwrite the other.
3. Make conflict resolution visible. Report which view is newer than the lock, and give a short instruction, such as restoring the rejected side, in the message itself.
4. Report the fallback. Return which view the loader served, or log the reason, so a consumer can alert on it.
5. Store a base snapshot. With the fields at the last sync on record, non-overlapping edits to different fields could merge, which the design currently forbids by choosing the safer rule.
6. Specify nested values. A formal packet grammar, with a fixed rule for precision, would retire the string drift and the two-decimal rounding together.
7. Measure the benefit. Run rosetta-bench against a real model, with a judge and a verified price table, and report the result for one small case as one small case.

The ProgramSpec kind belongs after items 1 to 5, because it would reuse the same engine, and a sync engine with a blind spot would carry the blind spot into a second kind.