twaco v0.1.49

Fixed

• A mashup parameter's default is written and read as Composer keeps it: the root property of
  the parameter's name (a JSON default as an object), with no DefaultValue in the parameter's
  definition. mashup describe and mashup param now see a default set in Composer.
• db query and db run check that the temporary Thing's generated name is free before importing
  it; a taken name was imported over and then deleted by the cleanup.
• db clean deletes a leftover temporary Thing only when its description is the one twaco gives
  it, not on its name and template alone.
• datatable copy refuses when the source returns another number of rows than it counted, and
  its read-back check needs one matching row for each copied row, so two equal rows need two.
• twaco types (and the refresh after sync, extract and adopt) writes every changed declaration
  file, and with types platform the platform cache, in one transaction under the workspace lock:
  a failure leaves the old set whole instead of some files new and some old.
• Taking the workspace lock removes only temporaries named as twaco names them, and warns about a
  lookalike instead of deleting it.
• Backup sets are pruned only after the forced push, forced deploy or delete they guard succeeds.
• A UTF-8 byte-order mark at the start of a sidecar (which a Windows editor may add) is read as its
  encoding, not its content: sync, check and adopt no longer see a script that only gained one as
  changed, no longer fold U+FEFF into the entity's script, and read a fields.json or
  content.json that has one. Extract, adopt and sync keep the mark when they rewrite the file.

twaco v0.1.48

Fixed

• Entity comparison hashes are version 10: stored JSON and QUERY values, VEC values, TIMESPAN and
  VARIANT defaults and nested INFOTABLE cells compare as the server stores them. Run
  twaco entity status --all --record once to record the new baselines.
• A TIMESPAN property default is sent in the form an import reads (start,end,period) even when
  the file holds the form the server exports ({period=…, start=…, end=…}), which an import
  misreads: before this, deploying a pulled TIMESPAN default reset or garbled it.
  thing property add --default accepts a TIMESPAN. A VARIANT default stays refused: a 10.2
  server imports it once and then fails every later import of the entity.
• A style or theme value holding ]]> can be edited and cloned after it is created.
• entity delete puts back the defaults it cleared to break a cycle when the entity is not
  deleted after all.
• MCP entity_new creates twaco.toml for a first project in an empty root, as the CLI does.
• thing property add checks that a VEC2-VEC4 default has that many numeric components.
• The rows of an infotable value compare by its own DataShape's types: a server stores a NUMBER
  cell 1 as 1.0, which read back as "not kept".
• Mashup parameters accept a JSON --default, and names holding -, non-ASCII letters or a
  leading digit, all of which the server keeps.
• Stored JSON and QUERY property values compare with their keys sorted, as the server stores
  them. Before this, a Thing with a persistent JSON or QUERY property whose keys were not in order
  read back as "not kept" after a deploy.
• new timer and new scheduler accept ]]> in --then and --script, writing split CDATA.
• entity delete breaks a cycle made by a THINGNAME property default that names a Thing of the
  set depending on the entity: it imports the entity without those defaults, then deletes the
  Thing first. Before this, the server refused both deletes.
• entity pull says when the entities are already in sync instead of "pulled 0 entities", and
  prints the entities it skipped for lack of a baseline when applying too. Its JSON adds in_sync.
• A ConfigurationTable cell is typed by the table's own fields only; a field of the same name
  inside an INFOTABLE cell no longer changes how the table's cell compares.
• entity pull given two names for one entity pulls it once instead of refusing.
• new scheduler writes a --cron holding ]]> as split CDATA instead of malformed XML.

Added

• thing property add --persistent accepts an INFOTABLE property, writing an empty table of its
  repository DataShape's fields as the stored value, as the server does. It was refused on the
  grounds that an import re-stamps the value, but comparisons have ignored that stamp since hash
  version 6.
• Properties, service parameters and DataShape fields take every base type of the 10.2 platform,
  such as XML, VEC2-VEC4, IMAGE, THINGCODE, TIMESPAN, VARIANT, GROUPNAME and PROJECTNAME. A
  persistent one gets the stored value the server writes for its type; a persistent TIMESPAN with
  a default, or VARIANT with one, is refused. VEC values compare as the doubles the server stores.
• Property, service and parameter names may hold - and non-ASCII letters, which the server
  accepts; a leading digit and a dot stay refused, as the server refuses them.
• mashup new --param takes an INFOTABLE parameter as name:INFOTABLE:DataShape[:DIRECTION],
  as mashup param add already did, and mashup parameters take every platform base type.
• ]]> is accepted in style, state, theme and menu values, in menu items, in AI agent text and in
  --run-as, written as split CDATA.
• new project in a folder with no twaco.toml creates one declaring the project.

twaco v0.1.47

Fixed

• Entity comparison hashes are version 9. Split CDATA payloads compare as their joined text,
  EventDefinitions and subscriptions compare by name, and declared LOCATION and QUERY values
  compare as the server stores them. Run twaco entity status --all --record once to record the
  new baselines.
  Before this, a script containing ]]> that the server stored trimmed read back as "not kept",
  and the next deploy was refused.
• new thing writes the stored value of each persistent property the Thing inherits from its
  repository templates and shapes, which the server adds on import.
• A failed project import shows the Importer's reason from the ApplicationLog (such as a name
  conflict or a bad index field) after the HTTP status.
• Deploy no longer re-imports a project whose entities are all already on the server; it reads
  them back and records their baselines. When deploy refuses, it prints what the other entities
  would do before the refusals.
• access explain says when the entity has no such service, or the server no such user, instead
  of answering "allowed" or printing a raw 404.
• thing property add writes DATETIME defaults in UTC milliseconds, and service, subscription,
  property-default and localization editing accepts ]]> by using split CDATA. new data-table
  writes semicolon-separated multi-column indexes, which the server accepts.
• check reports a property, service or event sharing a member name in one entity before the
  importer rejects it. appkey show preserves expiration milliseconds, call Thing.Service
  gives the two-argument invocation hint, and CLI summaries handle long gate names and singular
  occurrences correctly.

twaco v0.1.46

Added

• requirements.toml supports [optional.entities] for dependencies that are allowed to be
  absent from some target servers.

Fixed

• Entity comparison hashes are version 8. A NUMBER, INTEGER, LONG or JSON value whose type the
  entity declares compares by value (the server returns 10800000.0 as 1.08E7 and JSON
  compacted with sorted keys), PropertyDefinitions compare in any order, and an empty script
  equals the server's <code/>. Entities twaco authored no longer deploy as "not kept" and then
  get refused. Run twaco entity status --all --record once to record the new baselines.
  Adopt compares through the same rules.
• new timer and timer set write the update rate as the server does; thing property add
  refuses a LONG default beyond 2^53, which the server would round.
• init --from-server, entity pull and adopt keep a stored property value's Timestamp and
  Quality; without them the server refused the whole project import. Deploy refuses such a
  value before importing.
• entity pull --all names the entities it skips for having no baseline.
• The no-baseline refusal no longer prints runs of spaces; with --force, deploy shows the
  reason without the advice.
• model resolve answers 0 for a template or shape no Thing implements; types --check with no
  TypeScript installed says how to install it; an XSD whose occurrence counts overflow is
  refused instead of mis-validated.

twaco v0.1.45

Fixed

• The structure gate now finds the export schema in the Eclipse plugin JAR's nested
  platform-common JAR, and in an Eclipse distribution zip, without copying the vendor schema.
• User-scoped MCP registrations no longer pin TWACO_ROOT to the solution that configured them.
• types --check names the TypeScript version it ran, and refuses a compiler that does not
  report a known type error twaco plants, rather than reporting a silent compiler as a pass.
  TypeScript 7 reports fewer JavaScript findings than 5.x, such as a value that may be null.

twaco v0.1.44

Added

• twaco check has an offline, advisory structure gate. Set [gates] structure_xsd (or
  TWACO_STRUCTURE_XSD) to an XSD, Eclipse plugin JAR, or directory; the vendor schema is read
  only at runtime and is never stored by twaco. It reports unknown attributes, unexpected or
  missing children, text where only elements belong and values of the wrong type (a boolean that
  is not true/false). Child order, aspect.* attributes, server-computed sections, an empty
  ExtensionPackages, the empty Subscriptions a 10.2 export writes under a Thing, and
  collections the schema does not know are not findings.

Notes

• A fields.json written before 0.1.43 lists fields as its XML did. It still reads as in sync;
  the next extract of that DataShape rewrites it once, in ordinal order.

Fixed

• twaco sync leaves an unedited service script whose lines all end \r\r\n (a CRLF export
  checked out with CRLF conversion) alone again. Since 0.1.40 it counted those endings as mixed
  and rewrote the payload, so every sync reported the script as changed.

twaco v0.1.43

Changed

• twaco deploy and twaco entity push (MCP deploy: differences on each not_kept item)
  say where an entity read back "not kept" differs from what was sent: up to five paths such as
  Project[P]/@dependsOn: changed, compared as the hash compares them. Paths carry element and
  name attributes only, never a value.

Fixed

• twaco adopt rewrites a DataShape's fields.json and a DataTable's datatable.json along
  with the XML it adopts. They were left as they were, and sync, which reads them as the source
  of truth, put the old field description, type or aspects back. A sidecar edited since the last
  sync is never overwritten: the adopt is refused and nothing is written. A DataShape or
  DataTable the adopt creates gets its sidecar too.
• fields.json lists a DataShape's fields in ordinal order wherever its XML came from. A
  server export lists them by name, so a pulled DataShape's sidecar came out in another order
  than an authored one. A fields.json written in another order still reads as in sync.

twaco v0.1.42

Added

• twaco model resolve <ThingTemplates|ThingShapes>/<name> (MCP model_resolve): how many
  Things implement a template or shape on the server, and the first of them.

• twaco entity inspect <Collection/Name> (MCP entity_inspect): an entity's members on the
  server, each with what declares it, and with --values a Thing's current property values.

• twaco access explain <user> <Collection/Name> <service> (MCP access_explain): whether the
  user may invoke the service, from the server's run-time check and the entity's visibility
  through the user's organizations, with the reasons; the service is never invoked.

• twaco mcp configure <codex|claude-code|cursor> registers twaco's MCP server with the client:
  a plan until --apply, only twaco's entry added, the old file saved beside it, nothing done
  when the entry is already there, a different one replaced only with --replace.

• twaco mashup remove, mashup unbind, and mashup off (MCP mashup_remove,
  mashup_unbind, and mashup_off) remove a widget/subtree, one binding, or one event handler
  offline. Widget removal refuses unproven references; --cascade removes only the bindings and
  events it can prove depend on the widget and leaves orphaned data calls for review.

twaco v0.1.41

Added

• twaco sync --json and twaco bundle --json print the report the MCP sync and bundle tools
  return.
• scripts/live_smoke.py builds a small app on a disposable test server with twaco, checks after
  each step that the server kept what was sent and that every entity is in sync, and deletes it.

Fixed

• twaco localization set, new, remove, pull and push accepted --json and printed text;
  they print the JSON the MCP tool returns.
• twaco check (mashup bindings) reports a dropdown's or list's display or value field, or a
  chart's axis or data field, naming a field the result bound to the widget does not have.

twaco v0.1.40

Added

• twaco mashup add (MCP mashup_add) places widgets the solution's [[extension]] projects
  define: twaco reads a JavaScript TW.IDE.Widgets.<type> definition or a TypeScript
  @TWWidgetDefinition class and writes Composer's base properties plus the literal defaults the
  source declares. --prop reads a property with no default as its base type, or as JSON.

• twaco types --platform also caches the mashup builder's code of the extensions installed on
  the server, and mashup add places their widgets offline: web-component widgets
  (TW.Widget.widgetWrapper.config) and TW.IDE.Widgets definitions alike.

• A new check gate, project dependencies, names a project a Project file's dependsOn lacks
  although its Things or ThingTemplates use that project's ThingTemplate or ThingShape. The server
  adds such a project on import, which made the Project read back not kept (verified on 10.2; a
  base DataShape adds nothing).

• check finds a removed DataShape field still in use: the mashup bindings gate reports a grid
  column for a field the result bound to the grid lacks, and the result shapes gate a row the
  script adds to the result with a field the declared DataShape lacks.

Changed

• twaco call refuses an argument in the service's place (call Entity.Service limit=3 sent
  limit=3 to the server as the service name) and shows the form it meant.

• twaco entity status says when entity files are behind their sidecars, which it does not
  compare; an edited script or an adopt read as in sync before.

• twaco sync no longer leaves a carriage return from a CRLF script in an LF entity file, and
  repairs a file a sync left that way; mashup param add and set keep a CRLF mashup CRLF.

• twaco doctor (MCP doctor) reports the server's ThingWorx version and warns when it is not
  the version of the widget catalogue (10.2) that mashup add, new and validate judge widgets by.

• twaco adopt --apply refuses to create a mashup whose sidecar folder already exists, or that
  differs only in letter case from a mashup in the repository: creating it overwrote the other
  mashup's sidecars.

• twaco deploy (MCP deploy, added_dependencies) explains a Project read back "not kept"
  because the server added projects to its dependsOn: importing an entity that needs another
  project adds that project. The server keeps what the file declares otherwise, so pulling the
  Project once settles it.

• twaco mashup new refuses a name that differs from an existing mashup's only in case, which
  ThingWorx refuses too ("Already Exists, With Different Case", verified on 10.2); before, only
  a case-insensitive file system stopped it.

• twaco adopt lists conflicts and skipped entities under "not applied" rather than "applied",
  says "Nothing was adopted" when that is so, and, with no base, names the conflicting entities
  that are as last deployed to (or recorded against) the default profile's server, for which
  entity pull is the way.

• twaco deploy --apply reports "create" and "update" for what it sends, not "would create".

• twaco update prints the executable's path without Windows' \\?\ prefix.