Cifru Documentation

Detailed guide for users and AI assistants. Read-only data workspace builder for iPhone, iPad, Apple Watch widgets, and supported CarPlay widget surfaces.

Documentation updated: September 13, 2026. Developer / seller: Ionut-Madalin Dumitru. Contact: support@cifru.eu.

Read-Only Safety Model

• Cifru is designed for read-only display, filtering, sorting, exporting, and dashboarding.
• Database lists are generated from controlled UI fields. Normal users do not type editable SQL inside Cifru.
• SQL-style requests should be used with source-side read-only database accounts.
• API and ecommerce connectors use read requests. GraphQL mutation and subscription operations are blocked.
• Cached rows, exports, imported files, and viewed business data are stored on the device and are not sent to a Cifru backend.
• External widgets use a small local snapshot. They do not connect directly to databases, APIs, feeds, files, or ecommerce systems.
• AI Configurator initially sends only safe schema metadata: internal source/list IDs, display names, field names, field types, allowed widgets, allowed filters, allowed actions, bundled Cifru connector behavior, and user-approved public vendor documentation context. If automatic repair needs to verify a relation and the user has left minimal mapping samples enabled, Cifru may send at most one strictly reduced identifier-only sample per relevant object (maximum 12 bounded fields). Credentials, tokens, URLs, names/contact data, invoices, descriptions, prices, totals, stock, quantities, and other business values are excluded locally. Exact schema discovered from the configured source remains authoritative.

App Navigation Map

What Leaves The Device

Home Screen

First-install Demo button

On a genuinely new installation, Cifru adds one English-language Cifru Demo (local) Home example automatically. It demonstrates a customer-invoice header, a row-level Details section with invoice lines, and a Product sub-button on each line. Every row is sanitized and stored locally; the example never connects to a network source. The Demo source, three Demo lists, and two Demo relations are excluded from Free/Starter/Pro source, list, and Details-link usage, so the example cannot consume or unlock a plan entitlement. A visible DEMO badge distinguishes it from real screens. Deleting any Demo screen through its destructive action removes the complete bundled example and its local sample cache, without deleting or changing real sources. Once deleted, it is not recreated on ordinary launches.

The setup checklist intentionally ignores bundled Demo objects: it describes progress on the user's own source, fields, Home button, and Details relation. The existing Start with an example action remains available when the workspace is empty.

Header

Workspace Status Card

Shows the latest app status message and four small counters: lists, rows, warnings, and stale items. The rows counter is the sum of rows actually held for the active workspace lists, not the sum of their configured maximum limits. Use this to tell the user whether Cifru has data, whether warnings exist, and whether refresh is needed.

Setup Checklist

The checklist is expanded while the workspace has no Home button. After the first Home button is created it collapses automatically to keep Home compact, and the user can expand or collapse it again at any time.

Empty State Buttons

Home Toolbar

Source Categories And Connectors

Path: Sources > Add sources. The Add sources button opens a menu grouped by category.

Connector Verification Scope

Cifru uses the same production functions in its automated connector tests through controlled transport fixtures. This proves request construction, authentication headers, catalog parsing, pagination, response parsing, row limiting, and error handling without requiring customer credentials. A fixture test is not falsely described as a live guarantee for every server version, proxy, firewall, plugin, or permission model.

Sources Tab

Add Sources Area

Source Editor - Common Sections

Path: Sources > select a source.

Database Source Fields

Applies to SQL Server, PostgreSQL, MySQL, MariaDB, and Oracle.

Feed, FTP, API, File, Storage, And Shop Fields

Generic HTTP Authentication

The HTTP(S) feed, REST JSON, GraphQL, OData, and generic custom-shop API connectors share one vendor-neutral authentication layer. Automatic keeps compatible legacy settings; None sends no credential; HTTP Basic uses username/password; Bearer header uses an Authorization-style token; API-key header lets the user choose a valid header name; Query token lets the user choose the parameter name. Secret values are stored in Keychain and are not serialized into workspace JSON, copied into endpoint fields, shown in query transparency, or forwarded to a different scheme/host/port. Query-token mode builds the final URL with URLComponents, replaces a duplicate secret parameter, and keeps all other non-sensitive query items intact.

1.1 development: OAuth2 accounts for REST JSON

This section describes the isolated 1.1 development app, not the frozen 1.0 releases. In Sources > REST API, enable Connect with an OAuth2 account when the service uses browser sign-in. Enter its registered public client ID, authorization URL, token URL and read scopes; for example products.read offline_access only if those scopes are supported by that service. Register the displayed redirect URL exactly. Do not enter a client secret or put credentials in the endpoint. Provider-specific Google Drive and Microsoft setup are separate integrations and remain under validation.

Connect account opens the system browser. PKCE and a one-use state protect the return. Access and refresh tokens are stored separately in Keychain on iOS or encrypted Android Keystore-backed storage, never in portable source configuration. Studio checks the saved account locally, so merely reopening the editor does not trigger token refresh or erase a session when offline. Actual reads renew access when necessary; revoked access requires reconnecting. Disconnect removes this source's local session and keeps its configuration.

Account connection is not a completed data test. Choose a concrete read-only JSON endpoint, then test the returned rows and real fields in the existing Studio flow. OAuth reads use GET, the existing JSON parser and bounded pagination. A rejected continuation or pagination loop is an error, not a completed cache. Credentials are not forwarded to another origin. Cloud-file downloads have a separate redirect policy that strips the bearer token from preauthorized download redirects.

1.1 development: JSONL / NDJSON files

Studio explains this format in the main data-selection card, with an example, before you choose the fields. On Android, a local source keeps read access to the selected document: keep the file available and select it again if it is moved or access is revoked. This is not a promise that a permanent separate file copy was created.

Each non-empty UTF-8 line is one JSON object and becomes one row. Choose a .jsonl or .ndjson file, or choose JSONL explicitly for a file/feed without an extension. For example, {"sku":"A1","quantity":5}. Studio detects the fields; there is no worksheet or JSON array path. Nested object fields appear as product.name; arrays remain JSON text, not automatically linked tables. If a previously selected JSON array path remains, use the explicit clear-path action in Studio.

The development reader validates the complete bounded file, including lines after the preview limit, and selects matching rows before applying the row limit. It keeps precise numeric text and rejects malformed lines, ambiguous fields and oversized records instead of reporting a partial read as complete. Downloads still use the connector's whole-file safety limit. Cross-platform UI, cache and import acceptance is in progress; this is not a compatibility claim for the stable 1.0 apps.

1.1 development: network files and Paradox

If the selected Paradox table or its memo companion changes during a read, Cifru rejects that result and asks you to retry using a stable copy. This includes a memo appearing or disappearing while the table is being read; duplicate local table names are ambiguous and must be resolved. These checks reduce mixed-file results but do not replace a database snapshot or certify an actively edited WinMENTOR folder.

Cache data is not a shortened preview: memo text and missing (NULL) fields must be preserved. Android 1.1 now rejects cells or schemas that exceed its cache safety bounds instead of silently shortening values or dropping columns. If a complete new snapshot cannot be saved, the previous valid cache remains available. After upgrading a development build that shortened memo text, refresh the list to read the original values again. These changes do not modify the frozen 1.0 applications.

Paradox numeric filters use the table's number values: 125.50 and 125.5 match, while a missing value (NULL) is not zero. Text identifiers remain text, so 001 and 1 are distinct. Filtering happens while reading table blocks, before the preview row limit. Sorting uses the complete bounded result; NULL values sort first ascending and last descending.

The Android development source Network folder (SMB) reads an existing CSV, TSV, JSON, XML or XLSX file from a Windows server or NAS. Enter the server, shared folder name and a read-only account, then use Choose file. For \\server\Reports, the server is server and the share is Reports; do not enter both in the server field. Domain and required SMB 3 encryption are advanced account/security options. Cifru uses signed SMB 2/3 reads and does not create, edit or delete remote files. Structured-file downloads are bounded to 10 MB, with parsing and row filtering on the device. A changed or incomplete download must not replace a complete cache.

The iOS 1.1 development implementation includes the same server/share/account/file flow and production list reader. Its separate CI has passed signed and encrypted SMB protocol tests against a read-only Samba fixture, including real schema, preview and runtime reads. Final release validation remains separate.

Paradox is a separate file format, not another name for SMB. In the Android and iOS 1.1 development source editor, choose Paradox tables, then Folder on this device or Network folder (SMB). Select a real .DB table; keep its matching .MB memo file in the same folder. For a local source, select the containing folder, not just one file. In Studio, choose a table from that folder, preview its actual fields and configure cards, filters and Details. No SQL query, JSON row path or workbook sheet is needed. Cifru reads bounded blocks and applies filters locally before the row limit; it does not execute SQL, install BDE, or create lock/index files. Character encoding is automatic from the table header; advanced users can override it, for example with windows-1250, without changing the file.

The Android production reader has passed local-file, folder-selection persistence and actual SMB tests with independently generated Paradox tables, including NULL, decimals, diacritics and memo. The Swift reader has passed format, actual SMB and coordinated local-file tests; its new source/Studio integration is under validation. Folder access is kept locally: iOS stores a device-only security-scoped bookmark in Keychain, not in exported configuration. After transferring a configuration to another device, select the local folder again. These tests do not certify every WinMENTOR installation, encrypted table or unsupported field type. Use a stable read-only copy when another application is editing the tables: change detection is not a multi-file database transaction. These development notes do not describe the frozen 1.0 releases.

1.1 development: Google Drive and OneDrive / SharePoint files

The account card shows Connected when a source-specific account is saved securely on this device. This is separate from testing the selected file or endpoint: access is checked when reading. Reconnecting is an available action, not a required second login. Each source keeps its own connection.

Background cache: enabled automatic refresh can run without a visible app when the operating system grants execution time. Android requests a deduplicated catch-up on minimization; iOS schedules its next opportunity before waiting for reads. The configured minutes are a due threshold, not an exact timer. Battery-saving modes, suspension, network availability and force-stopping can delay or prevent execution. Multi-minute iOS partition rebuilds still require further long-work/resume validation; these development changes do not guarantee uninterrupted background completion.

Start at Sources > Add source > Cloud files, then choose Google Drive or OneDrive / SharePoint. S3-compatible storage remains in its separate category. Use a recognizable name such as Personal Drive or Company OneDrive. Multiple sources may use the same account or different accounts; each source retains its own account binding and selected file. Disconnecting one source must not sign out the others.

Cloud and SMB CSV/TSV reads preserve quoted line breaks and long cell values. A malformed row, ambiguous column name or oversized cell is reported instead of silently shortening or shifting its data. Use unique, non-empty column names (at most 200) and compact exports; a single text cell is limited to 1,048,576 UTF-16 units. These safety checks protect existing cached data.

For example, a row limit of 1 with the warehouse filter Central means the first matching Central row, not the first row of the downloaded file. A descending numeric sort must select the largest matching value before the limit. Cloud/SMB files are selected locally; OAuth2 API reads may need several pages before the bounded result is known. Reaching a safety limit reports an incomplete read instead of pretending the first page is the whole result.

A CSV or XLSX file can contain valid column headers but no data rows yet. The new cloud/SMB Studio setup keeps those real fields available and shows an empty preview; it does not invent an example row. A missing worksheet or malformed header is a different condition and requires correcting the selected file or sheet. OAuth2 connection tests use the same saved source account as runtime reads; a refused or expired authorization is never reported as a successful connection.

For cloud/SMB spreadsheets, give each column a clear, unique header. An explicitly empty header is shown as Column B, for example, so its values remain available. Duplicate cells, values outside the declared columns and unsafe compressed files are reported as an invalid read, even if they occur after the requested preview rows; they are not silently ignored or saved as a complete cache.

Numeric filters distinguish 0 from an empty or invalid value: text such as unknown does not become zero. If a selected filter or sort column disappears, choose its replacement in Studio; Cifru reports the change instead of saving a misleading empty result. Spreadsheet formulas are not executed by Cifru. Their saved results, including zero and intentionally empty text, are readable. If a formula has no saved result, open and recalculate the file in Excel or its spreadsheet application, save it and retry.

List search works across the currently loaded selection before dividing it into display pages. Leading or trailing spaces do not change the search, and clearing it restores that selection; search does not silently download unrelated source rows. A read-only custom SQL query does not also need a separate table name. Plan permissions, read-only validation and genuine connection or data-limit warnings still apply.

Choose the cloud source, connect an account, and browse folders to select a CSV, TSV, JSON, XML, XLSX file or Google spreadsheet. For example, choose Inventory.xlsx, then its Products sheet in Studio, preview rows, and choose the actual code, name and quantity columns. File IDs are retained separately from displayed names. Cloud transports do not execute SQL: a complete file up to 10 MB is downloaded before local filtering. A file that changes during download is rejected without replacing a valid cache. Google Sheets are exported read-only to XLSX so worksheet selection remains available.

Google on Android uses the operating system's Google authorization service and binds each saved source to the chosen account. iOS uses its registered native OAuth client and PKCE browser flow, with refresh credentials in Keychain. Microsoft uses its registered native OAuth application; additional site/library permission must be granted by the user's organization when needed. Successful sign-in is shown separately from successful file/schema verification. These development integrations and test registrations are not production release approval; real account validation is recorded separately.

The Google Drive and OneDrive apps do not need to be installed: Cifru browses and reads files directly through the providers' APIs. The current Android Google authorization path requires Google Play services, which is a separate system component, not the Drive app. If those services are disabled or outdated, Cifru explains that they need to be enabled or updated when supported by the phone; it does not treat that condition as an expired account. Devices without Google Play services need a separately supported authorization path; do not assume that installing Drive solves that limitation.

If an account service takes too long to respond, return to the source and try again. A timed-out attempt does not delete the previously saved session or cached rows. Explicitly disconnecting one source keeps other sources connected.

Home updates the visible age of a saved cache while the app is active and when you return to it. This is only a display update: it does not trigger an extra source read or change the automatic refresh interval.

1.1 development: consistent navigation and readable forms

Home, Build, Sources and Settings use the same grouped navigation pattern on Android and iOS, including their Studio, account, cache and preference pages. Use the back chevron to return and the three-dot button for page actions. The selected bottom tab remains highlighted. Red guidance continues to mark the next required setup field; it is not a connection failure by itself.

Long page titles and values may wrap onto a second line, especially with larger system text. Source names, hosts and file paths share the available row width with their labels rather than hiding them. Light, Dark and Eye Comfort appearance applies to forms and menus as well as the main pages. Cloud account connection is displayed separately from verification of the selected file: a connected account does not guarantee that every file is readable.

For a cross-platform video guide, use the same application language, appearance, text size and sample workspace. Android and iOS keep their own system sign-in, permission and file-selection dialogs; these are not additional Cifru setup steps and may look different. Some development-language strings still fall back to English. These notes describe 1.1 development, not changes to the frozen 1.0 releases.

Home Button Assistant

1.1 development: New buttons in Basic mode use five steps: Data, Appearance, Filters, Actions, and Preview. The numbered indicator highlights the current step, not completed validation. Back and Continue stay below the editor. Examples and checks before saving expand on request. Filters are optional; sub-buttons are required only when you choose the Home-with-Details recipe. Appearance separates the Home button name/icon from the fields shown in each list row. Preview can use a bounded sample from the successful data test; it does not create a complete cache or report a total row count. Changing the source, query or selected fields invalidates that sample. Existing configurations remain unchanged.

Path: Build > Home screens > Choose source and table/path. This is the easiest path for non-programmers. The source editor is only for connection settings and connection testing; tables, views, endpoints, sheets, and feed paths are chosen here while creating a Home button.

Studio adapts this choice to the source family. Known ecommerce objects are shown as localized business choices such as Products, Orders, Customers, Categories, Coupons, and Collections while Cifru keeps the connector route internally. Unknown or custom store objects are never given an invented label: their exact object name or path is shown. Feeds, FTP files, local CSV/TSV/JSON/XML/XLSX files, and S3-compatible objects use the configured file or object as the guided starting point; workbook sheets and detected structured-data fields are offered after preview. Generic APIs use the verified root or endpoint, and manual technical paths remain available in Advanced mode.

Build Tab

Path: Build. This tab is for configuring the workspace after sources exist.

If there is no successfully tested source, Build shows a prominent warning and a highlighted Go to Sources button. The Sources tab also shows a badge until at least one enabled source has a successful connection test. This is intentional: users should configure and test a source before building lists, Home buttons, Details, or widgets. Once a source is OK, Build shows the guided Create a screen action, where the user can choose a screen type, source, and table/path, preview rows, and create the first Home screen without guessing which technical area to open.

In Cifru builder editors, Save stores the current settings, shows a short visible confirmation at the top of the editor, and keeps the user on the same screen. Use the Back button when finished editing. This lets the user save, preview, test refresh, and continue adjusting without being sent back to the previous category.

Build uses a hybrid organization. Basic mode starts with a compact tree of what the user actually sees: each Home screen is a parent row, its Details screens are nested children, and cross-source enrichments are shown under the screen where their values appear. Tapping a normal screen opens one Studio with five contextual tabs: Card, Data, Filters, Actions, and Preview. Card is the default tab so the first view matches what the user recognizes on Home. Its visual layout editor has separate Compact card and Full detail surfaces. A user can enable or hide fields, rename labels, choose text/link/image/location presentation, promote totals or statuses as highlights, group information, enter Edit mode, and drag fields into a page-specific order. A Location presentation treats the edited field as latitude, pairs it with a longitude field from the same row, and may use another row field as the pin label. Compact cards render a static MapKit snapshot that opens Apple Maps; Full detail renders a MapKit map. Coordinates always come from the read-only source data: Cifru does not request or read the device GPS location, add background location capability, or call an external geocoder. A recommended-layout action keeps useful business fields prominent and moves technical identifiers out of the compact card. Guided shortcuts may open Data or Actions directly when that is the next unfinished step. This removes the need to understand three parallel technical areas before making a useful screen.

Cross-source mapping uses the same novice-first approach for ecommerce, databases, APIs, feeds, FTP, local files, and object storage. Known identifier families are presented with localized business names and may be suggested across equivalent fields, for example Product code / SKU to Barcode / EAN / GTIN or Order ID to another order identifier. Every choice still stores the exact source fields. Unknown fields keep their exact names without an invented alias. The editor identifies both lists and sources, explains the selected pair in one sentence, checks representative values from both read-only sources, and blocks saving when no real common value can be verified. Technical field names remain visible in Advanced mode.

Each main row in Your screens has an up/down menu. Reordering a main screen moves its complete navigation tree as one unit, including nested Details screens, sub-buttons, linked/enrichment data, and saved relation references. The resulting main-screen order is also the Home order. Child rows are intentionally not reordered independently from this overview because their presentation belongs to the parent screen and is configured in Studio. Deleting a Home button also removes its private hidden sub-button screens and then removes related lists and relations only when no other button, sub-button, enrichment, or widget still uses them. Shared configuration is retained, and this local cascade never deletes rows or objects from the external source.

The Create a screen action offers two guided screen types: Home button with list and Home button with Details. A new Home screen follows one uniform sequence: name the screen, choose the configured source, then open Choose table/path and fields. This third step is the exact same data editor used later in Studio > Data, so table/view/sheet/endpoint/feed discovery, field selection, preview, and Pro Advanced custom read-only queries are never duplicated in a second setup surface. After the data is verified, the user continues in the same Studio. Home button with Details opens Studio at Actions, where a reusable child list becomes a button on every matching card; it is not shown as an unrelated second Home button. Widgets have one manual creation path: Build > Widgets > Manage widgets > Add widget. Cross-source values are added under Studio Data or Actions through a common field rather than through a separate builder recipe. The AI Configurator remains a separate visible toolbar action in the upper-right of Build.

While a new screen is still a draft, Studio shows a short completion checklist: readable table/path or tested custom query, real fields selected, card layout completed, and, for the Details recipe, one successfully tested per-card Details action. The final Save action remains unavailable until the required steps are complete. Cancel removes only temporary draft elements created by that flow.

Creating and editing a screen is transactional from the user's perspective. Canceling a new draft removes its temporary screen and any list created exclusively for that draft. If the user chose an existing list, canceling removes only the new screen and preserves the reused list and every other screen using it. Leaving or discarding unsaved changes on an existing screen restores the saved screen and never deletes it; deletion is available only through a separate destructive action and confirmation. Saving keeps the screen and continues with the same Studio controls.

Screen and data-list deletion remain dependency-aware. Cifru shows a discreet usage summary under each list (Home screens, Details screens, widgets, relations, and actions) and offers explicit list deletion from both the screen/list overview and the Advanced data library. Removing the last Home screen, Details button, widget, or relation that uses a list automatically removes that now-unused list and its local cache; if another element still uses the list, it is preserved. Deleting a list directly first explains that its local screens, widgets, relations, and actions will also be removed; it never deletes or writes source data. Deleting a saved relation removes its Details/enrichment actions and removes either endpoint list only when that list has no remaining use.

Every Studio entry begins with a What you are editing identity card. It distinguishes a main Home button, a Details/sub-button screen (including its parent and relation), a sub-button destination, linked/enrichment data, and a new temporary Home draft. When Studio Data opens the shared list editor, the editor repeats the linked-data identity so the user does not mistake source/list settings for the main Home card layout. Each context edits its own saved page presentation and actions while reusing the underlying read-only list where appropriate.

Studio also keeps one deterministic What is missing before Save? checklist: source, metadata, object/path or custom query, fields, read test, then Ready. The compact screen tree derives Ready, Retest required, Incompatible, or Incomplete from that same state and opens the concrete editor when tapped. Loading never highlights a later step, changing a read-relevant source/object/query/path/field invalidates the previous test, and schema drift reports the exact unavailable fields without deleting the user's configuration. Removing a referenced field first lists affected screens, widgets, relations, enrichments, and calculations, then—only after confirmation—cleans the incompatible references while preserving valid ones. Studio Preview uses the same card/detail rendering and saved after-load filters/sort as Home. Disabled or blocked actions remain tappable enough to explain the missing prerequisite. Community provider/session checks run in the background and never delay anonymous browsing or Import Configuration; authentication remains necessary only for account and publishing actions.

Advanced mode reveals the underlying Data library, Relations map, and Common fields. These views edit the same lists and links used by Studio; no setting or capability is removed. Lists without a Home screen remain available in the Advanced data library because they may feed a widget, Details action, or cross-source enrichment. Every list shows its current usage and has an explicit dependency-aware delete action. Deleting the last Home screen, Details button, widget, or relation that uses a list now removes that list and its local cache automatically; a list shared by another element is preserved. A deliberately created standalone draft remains available in the Data library but is not treated as an active synchronization job until a screen, widget, action, or relation uses it. With an active Pro subscription, SQL-backed lists also expose an optional custom read-only query editor. The editor accepts a complex SELECT/WITH block with CTEs, joins, unions, cases, windows and aggregations against the selected connection. With explicit approval, its AI helper first researches official public manuals, uses bounded object and generic field terms to inspect the live catalog, and generates only from the exact discovered schema. A contradictory documentation plan degrades to schema-first generation. An independent coverage critic may request one bounded correction, but it cannot override exact local validation and the bounded live read. The current SQL draft remains visible for inspection and copying; Save stays disabled until that exact text passes the read-only test. Authentication, permission, network, TLS and timeout failures are never sent back to AI as repair tasks. The same editor exposes a visible Test read/Test and preview action, and a successful custom-query test is carried back into the new-screen checklist. When a valid imported or AI-created list already contains a custom query, Basic mode shows a clear Custom read-only query summary, source, field count, test state, and a read-only View query action; editing the SQL still requires Pro Advanced mode, while replacing it with a table or view is an explicit confirmed action. Changing its mapped source preserves the query and fields but invalidates the successful test until the exact configuration is tested again. Basic mode never asks a novice to write SQL.

Named parameters for targeted SQL: a Pro custom query may use one or more value placeholders such as :product_id or :from_date. Studio detects every placeholder and shows the same parameter card on iOS and Android, where the user selects Text, Number, or Date and binds it to a parent-row field, an opening-filter value, a fixed non-secret value, or Today with a day offset. Cifru requires an exact one-to-one match between placeholders and definitions, escapes and types every value for the selected SQL dialect, and never treats a value as an identifier or executable SQL. A query that depends on parent/opening context is forced to Live mode, has automatic global refresh disabled, and can run only with the matching context; it cannot accidentally build an unfiltered global cache. This supports any compatible read-only function or view and is not hardcoded to one ERP report.

Fast custom-query verification: Verify read-only structure checks the exact SELECT/WITH block, parameter definitions, and returned column schema through a zero-row database probe. It does not execute the business report or wait for a heavy join to return sample rows. Normal table/view tests retain their bounded row preview. The portable Community JSON stores the same parameter definitions on both platforms, contains no credentials or row values, and is rejected before import or moderation if a parameter is missing, duplicated, invalid, or unused.

Responsive large-data behavior

Large read-only loads use a responsive pipeline on both platforms. Network and file I/O, row materialization, filtering, sorting, relationship matching, enrichment projection, and export preparation run away from the UI thread. Work for a screen that has been left or superseded is cancelled or ignored, connector concurrency is bounded, and one coherent result is published only when its processing stage is ready. Cifru keeps the last valid cached content visible with local progress and error states, so Home, Back, tabs, and navigation remain usable while a live read, refresh, or cache update is in progress.

Lists Editor

Path: Build > Lists > select list.

Advanced Read-Only Queries (Pro)

Paths: Build > Create a screen > Home button > name > source > Choose table/path and fields > Custom read-only query, or Build > select a screen or Details list > Data > Choose table/path and fields > Custom read-only query. Both paths use the same validation/test rules. Creating or editing SQL is available only while Pro and Advanced mode are active; an existing valid query remains clearly identified and viewable read-only in Basic mode. It works for a new or existing Home list and for a list opened by a per-card action.

Exact Query block contract for users and AI assistants

Query parameters: values supplied by the current screen

In the shared custom SQL editor, named placeholders such as :product or :since reveal Query parameters. Choose each value's type (Text, Number or Date) and where it comes from: a parent-row field, an opening filter, a fixed non-secret value, or Today with a day offset. For example, a product's movement sub-button can use the opened product's identifier and Today minus 90 days. You are not choosing search fields here. A placeholder supplies a value, never a table name, column name or SQL fragment.

Context is mandatory when a parameter uses a parent field or opening filter. Cifru does not run that query globally without the context and does not build a whole-list automatic cache for it. Structure checks may bind typed neutral values without running the report; real execution needs the chosen context. A small preview can still be slow when a source function does expensive work. A function name is not an exception to read-only checks.

For package authors, these definitions are stored in the dataset's queryParameters array. Every placeholder must have exactly one definition; names are unique ignoring case. Parameters inside SQL string literals, comments or quoted identifiers are not bindings. The following is only a dataset fragment, not a complete import package; replace example field names with the actual mapped fields.

"queryParameters": [
  {"id":"A2283B5A-70A5-4B45-A46D-2507E47AB648", "name":"product",
   "type":"text", "source":"parentField", "fieldKey":"product_id",
   "constantValue":"", "dayOffset":0},
  {"id":"17E342C4-F4C6-44D1-A234-CAC13729D0AC", "name":"since",
   "type":"date", "source":"today", "fieldKey":"",
   "constantValue":"", "dayOffset":-90}
]

Community carries symbolic source slots, configuration and mappings, not saved accounts. Recipients connect their own source and grant access to their own cloud file or folder. Access/refresh tokens, client secrets, account-session material and device folder bookmarks are forbidden even inside nested package objects. A technical column named accessToken is merely metadata; exporting its secret value is not allowed. Existing packages still require local source mapping, plan checks and compatible fields before Apply.

The text pasted into Create calculated, grouped, or combined results > Query block must be SQL only. Do not paste Markdown fences, JSON, a title, an explanation, connection details, or credentials. The query must use the dialect of the selected connector: SQL Server, PostgreSQL, MySQL, MariaDB, or Oracle.

1. Return exactly one statement that starts with SELECT, or with WITH whose final statement is SELECT. A single trailing semicolon is tolerated, but omitting it is recommended.
2. CTEs, nested SELECTs, JOINs, UNION/UNION ALL, CASE expressions, aggregates, GROUP BY, HAVING, and window functions are accepted when they are valid for the selected database engine.
3. Do not use a top-level ORDER BY. Cifru applies its final sorting, filters, and bounded row limit around the query. Use Studio sort rules for final presentation.
4. Do not use parameters or placeholders that Cifru cannot bind, temporary tables, variables, dynamic SQL, stored-procedure calls, multiple statements, or commands that write, administer, lock, delay, import from, or export to another system.
5. Give every calculated expression a unique, stable column alias. Return a flat row made of scalar values suitable for Text, Number, or Date fields.
6. Use only tables, views, and columns verified in the selected source. The query contains no host, database password, token, API key, or connection string.
7. For a Details sub-button, include the child relation key in the final SELECT. Cifru maps that returned alias to a field from the parent button outside the query. Example: the parent result exposes gestiune, the custom child query also returns gestiune, then Studio links Parent button · gestiune to Details sub-button · gestiune.
8. For grouped results such as Top agents, decide the row grain explicitly and return both the identity and measures, for example gestiune, agent, document_count, and line_count. If a date condition must change which source rows enter an aggregate, express that condition inside the SQL or expose a suitable pre-aggregation grain; a local filter applied after loading cannot recalculate an already aggregated result.
9. After pasting, tap Test and preview. Save is enabled only for the exact SQL text that passed local read-only validation and returned a non-empty bounded live preview of at most 20 rows. Any edit invalidates that test.

Prompt that can be given to an AI

Valid SQL Server example: grouped result usable as a Details sub-button

The example demonstrates the required shape, not universal NexusERP object names. An AI must replace the illustrative view and columns only with objects discovered in the user's selected database. In Studio, an existing query such as Top agents remains identified and viewable in Basic mode; Pro Advanced can open its Query block, edit it, run the required bounded test, and save the exact tested text. The same editor is used for Home lists and Details/sub-button lists.

Common Fields

Path: Build > Common fields. Common fields make cross-source mapping user-friendly. A common field is a semantic annotation and normalization rule, not a relation by itself. Under every common field, Cifru discreetly reports whether it is unused or which list mappings and saved relations currently use it.

Data Links / Details

Path: Build > screen > Studio > Actions for a Details section/shortcut on every card, or Studio > Data for extra values shown on the same card. Advanced mode also exposes Build > Link data as a technical relation map. A data link takes one concrete value from the opened parent row and reads only child rows whose configured field has the same value. It is read-only and can power either a one-to-many Details button/section or a card enrichment. The map now states this role, both concrete list/field endpoints, whether the relation is available under the active plan, and exactly which screen currently uses it; unused saved relations are identified as such.

Optional live Details refresh: it is disabled by default. In Basic mode the user enables it and chooses a simple 5, 10, 30, or 60 second interval. Advanced mode also accepts an exact 3–300 second value and explains that the list must have a stable unique row key. While the individual Details screen is visible and the app is active, Cifru rereads only that row by its key. Reads are sequential, stop when the screen closes or the app becomes inactive, and never turn the whole list into live cache mode. A failed read keeps the last valid value and shows a small warning. Short intervals can use more network and battery. This is foreground record polling, not device-location tracking or background tracking, and it requires no location permission.

Card Fields From Other Lists

Path: Build > Home screens / buttons > select screen > Fields from other lists. This is the simpler choice when the user wants a few values from one matching row to appear on the same card.

Home Screens / Buttons Editor

Path: Build > Home screens / buttons > select screen. Home screens open lists from the app Home screen and define the mobile card experience.

Use this editor for the normal master-detail flow. For example, Supplier invoices is the main list/card screen, and a Details shortcut focuses invoice lines by matching id_document from the opened invoice to id_document in the invoice-lines list. The invoice header, highlights, metadata, and lines stay in one document workspace. The details list can come from the same source or a different source.

Mental model for non-programmers: the list/table is what Cifru reads; the Home button is how the user opens that list on the phone; Details is a related section for matching child rows; Fields from other lists adds a few values from one matching row onto the same card.

Details Assistant And Card Actions

Path: Build > select a Home screen > Studio > Actions > Add Details.

Use the Details Assistant for the normal non-technical flow. The user should think: "When I open one invoice/order/project card, keep its header visible and show me the matching rows from this other table/list below it." The assistant keeps all required context visible: main list, details list/table, field from opened card, field in details, matching rate, presentation mode, row style, preview limit, and an example before saving.

Example explanation shown in-app: if the opened invoice card has id_document = 123, Details should show only rows from the invoice-lines table where id_document = 123. This prevents users from confusing Details with a separate top-level Home button.

Advanced path: Build > select a Home screen > Studio > Actions > Open another list / Open URL.

Widgets

Path: Build > Widgets. Basic mode exposes guided Count, Sum, and Current value controls, field pickers, date-period presets, and simple conditions. Current value is connector-neutral: it can show the latest or otherwise sorted value from a database, API, feed, file, ecommerce source, or another configured read-only list, such as a sensor reading, ticket status, exchange value, or latest order state. Advanced mode additionally exposes Average, Minimum, Maximum, Top list, native in-app Line/Bar charts, manual technical keys/types/operators, sort internals, and the explicit Cache versus Live-query choice.

For SQL Server, PostgreSQL, MySQL, MariaDB, and Oracle metric widgets, Cifru sends one generated read-only aggregate query such as SUM, COUNT, AVG, MIN, or MAX to the selected concrete table/view. The result is therefore not calculated from only the first 100 displayed rows. Date presets are applied at the source before aggregation. Feed, file, API, and commerce widgets use the compatible connector's bounded filtered read path.

Widget Editor Controls

Opening Filters, Conditions, And Sort Rules

For supported SQL and connector reads, fixed filters and a selected opening-filter value are passed to the source before the final row cap, so Cifru does not need to download every warehouse/store just to show one selection. Opening-filter choices use bounded distinct-value discovery where supported. With Cache mode, the selected value is also applied locally to the full cached data and the resulting page partition is retained without replacing the full cache. Free-text search operates over all rows already loaded for that list, before UI pagination. By default, Cifru searches the visible Text fields shown on each card; Advanced mode can explicitly narrow or change that local search scope. Field choices use friendly labels and stay collapsed until the user asks to customize them. If a list is limited to 100 rows, search can inspect only those fetched rows; increase Max rows, turn the limit Off, or use a source-side period/filter when broader coverage is required.

Every open list also offers Scanner EAN / QR in its three-dot menu, between Filters and Export XLSX. Enabling it adds a barcode icon inside the right side of Search. Tapping that icon opens a compact camera sheet that recognizes EAN-13, EAN-8, UPC-A, UPC-E, Code 128, and QR, then places the value directly into Search. The camera uses continuous autofocus and exposure, recenters focus when the scene changes, and supports tap-to-focus. The user can use the visible Scan now button for a deliberate capture or enable Detect automatically; automatic detection applies the first valid code to Search as an immediate submit and closes the camera. Camera access is requested only when the scanner sheet is opened, the preview is released when it closes, and no photo or video is saved or uploaded by the scanner.

Browsing Data And Export

When a Home button opens a list, the user sees rounded mobile cards with title/subtitle/badge fields, an ordered grid of selected values, opening filters, search, sorting, row buttons, and paging. When Require filter selection when opening is enabled, Cifru waits until every required filter has a value or the user chooses Show all. Show results remains actionable so it can explain an incomplete choice: if one or more required filters are still blank, Cifru keeps the list closed and highlights exactly those filters with the shared red required-step cue. When required selection is disabled, the list opens immediately and those controls remain optional filters above the rows. After rows are present, the three-dot menu exposes Filters for local conditions and sorting. These runtime rules operate only on the rows already loaded on the phone: Apply is temporary, Clear temporarily shows the unfiltered loaded result, Reset to Studio default restores the saved screen behavior, and Save as default in Studio stores the current local rules on that one screen. None of these after-load actions changes SQL, API parameters, file paths, FTP/object-storage reads, connector behavior, or the row limit, and none triggers a source reload. Opening a row creates one composite workspace: hero header, important values, grouped metadata, and related sections. The first automatic Details link is inline and later links are collapsible; Studio can instead choose tabs or a separate screen. A parameterized related read is owned by the data runtime rather than by the temporary visible section: scrolling the section out of view does not cancel the read, and the empty-state message is shown only after the first read really completes. Child rows open in an inspector without losing the parent context. The same layout engine is used for a list opened by a Details or Open-list sub-button, and Studio Actions provides a direct Customize-cards link for that destination screen.

Portable meaning of after-load defaults

For configuration authors and AI assistants, after-load defaults are screen presentation metadata, not connector filters. The native workspace stores them separately from source/read filters as localViewFilters and localViewSortRules. Each filter references a real field, its declared type (text, number, or date), a supported operator, and the required value or range; each sort references a real field, type, and ascending/descending direction. Portable/Android configuration uses fieldId; the iOS native workspace uses the equivalent canonical field key. A package converter must resolve that reference against the real mapped field and must never guess a missing field. Omit these arrays or use empty arrays when no local default is intended. Never translate an after-load default into SQL, OData, REST parameters, an ecommerce endpoint, a feed URL, a file path, or an object-storage prefix.

Settings

Lists are managed only from Build, where their screen, relation, and field context is visible. Settings intentionally does not duplicate the list inventory. Cache & Sync still shows per-list cache/refresh diagnostics because those controls describe runtime state rather than list configuration.

App Mode / Use As App

Path: Settings > Branding and app mode. This is how a configured workspace can feel like the user's own native app.

Subscription Limits

StoreKit 2 loads the Starter and Pro product names, descriptions, localized prices, and billing periods from App Store Connect. Cifru does not invent fallback prices. If products are unavailable, the screen shows an error and Retry. Restore Purchases uses the user's Apple Account, and Privacy Policy plus Terms of Use remain available on the same screen. Local Debug builds can use a Pro development entitlement; Release and TestFlight builds begin at Free while StoreKit checks the current entitlement and never treat a plan stored in the local workspace as purchase proof. After a successful verified purchase or transaction update, Cifru activates the verified plan immediately and serially reconciles it with Transaction.currentEntitlements and the verified subscription status. The subscription screen distinguishes active, billing grace period, billing retry, expired, revoked, and verification-failed states. A verified billing grace period keeps paid access active; billing retry without grace does not. TestFlight purchases run in Apple's accelerated sandbox renewal environment and do not charge real money.

A subscription unlocks the self-service features of its plan. It does not include personalized installation, source administration, credential creation, mapping, query-writing, migration, monitoring, or configuration services unless those services are agreed separately in writing. The user or their administrator configures and validates connected systems and results; Cifru's read-only checks, documentation, AI suggestions, and Community templates assist that work. Mandatory consumer rights remain unaffected.

If a subscription expires, is revoked, or moves to a lower plan, Cifru returns to the applicable lower plan and keeps the user's local configuration so it can be restored later. Home and Build continue to show buttons and Details links that exceed the active entitlement in their original order, using a pale rose card, outline, lock icon, and an explicit reason rather than color alone. Tapping one explains the exact source, list, custom-query, relation, or cross-source limit and offers a route to the available plans; it never starts a read. On Free, the first eligible lists used by visible Home buttons remain active in Home order, followed by any eligible standalone lists, so users can reorder Home to choose deterministically what remains available. Locked sources, lists, relations, pages, and widgets cannot test a connection, browse tables/endpoints, preview or read rows, refresh in the foreground or background, publish external widget data, or be sent to the AI Configurator as usable metadata. Reactivating an eligible entitlement restores access automatically without recreating the preserved configuration.

Settings path: Settings > Subscription Plans. Product IDs: com.madalindumitru.cifru.starter.monthly and com.madalindumitru.cifru.pro.monthly.

Siri, App Shortcuts, And Apple Intelligence Readiness

Cifru exposes a small set of safe App Intents/App Shortcuts so Siri and system surfaces can help users reach the right setup area. This is the public Apple-supported path for Siri/Apple Intelligence integration on current iOS releases and is the safest future-compatible anchor for newer iOS versions.

Important: Siri/App Shortcuts are navigation and guidance helpers. Cifru does not send database credentials, API keys, cached rows, exports, or imported local files to Siri or to a Cifru backend. The app does not depend on the legacy SiriKit capability for this flow; it uses App Intents/App Shortcuts.

Widgets, Apple Watch, And CarPlay

Cifru external widgets read a local snapshot created by the iPhone app. They do not open network connections directly. This is important for safety, App Store review, and privacy.

• iPhone Home Screen widgets can show selected dashboard widgets.
• Lock Screen accessory widgets can show compact values.
• Apple Watch uses WatchConnectivity to receive every widget marked for external display, then Watch complications read the Watch-side snapshot. Cifru publishes the newest revision through application context, sends it immediately while the paired Watch is reachable, and queues the latest revision for background delivery without cancelling a transfer already in flight. It uses the dedicated current-complication transfer when watchOS reports available budget and a background user-info transfer otherwise. A failed latest background transfer receives two bounded retries with backoff instead of being silently discarded. The Watch extension retains a WatchConnectivity background task until pending content has been processed, accepts only a newer revision, saves it atomically, reloads its timelines, and returns the applied revision to iPhone. If a newer iPhone snapshot appears while one transfer is pending, only that newest revision is sent next. Settings distinguishes a snapshot published by iPhone from a revision actually confirmed by Watch. Delivery remains best-effort and scheduled by iOS/watchOS rather than guaranteed at an exact minute. On watchOS 10 or later, the gallery exposes one preconfigured Cifru recommendation for every selected widget, named with the title configured in Cifru; the title does not depend on the Watch language.
• To add a Watch complication: enable external display in the Cifru widget editor, update the widget snapshot, open Cifru once on the Watch to allow synchronization, long-press the Watch face, tap Edit, choose a complication slot, and select the desired Cifru entry by its configured title. watchOS 9 shows the first selected widget as a compatibility fallback.
• Inline and rectangular Watch layouts preserve the configured title and scale the value to fit. Circular and corner layouts use a compact value such as 57.2K while keeping the full title/value available to accessibility.
• Full widget values follow the device locale. Thousands grouping is preserved, integers show no decimal part, and non-integers show exactly two decimal places. For example, a Romanian device displays 57154.22 as 57.154,22, while 57154 displays as 57.154.
• CarPlay support is widget-only through WidgetKit small widgets where supported by iOS. Cifru is not a separate CarPlay app target.
• The minimum and default external widget snapshot refresh request is 15 minutes. This is a best-effort due threshold, not an exact timer; iOS controls the execution opportunity and may refresh later according to battery, network, and system activity.

Cache Guidance

In 1.1, Home shows an active cache refresh separately from the last completed read. Relative age labels advance while Home is visible, without querying the source. Deleting an unused button/list retires its queued or running work; a list still used by another button or widget is preserved.

When an opening filter selects one fully downloaded partition, that selection can be displayed while the other partitions are still loading. It is explicitly labeled provisional until the complete cache is published. It does not replace the last complete snapshot or advance its timestamp or total row count. Unfinished or invalid partitions are never presented as complete.

The minimum automatic cache refresh interval is 15 minutes. The configured interval means that data becomes due for refresh after that time; it is a best-effort target, not an exact background timer. iOS decides when Cifru may run and can delay execution according to battery, network, and system activity. Cifru catches up at every granted background opportunity and whenever the app becomes active; due foreground refreshes use the same fair two-slot coordinator as manual work. An optional metadata-only relay mode can wake the same bounded read-only queue after a source-change event, while retaining the iOS-managed fallback. The relay event never contains source rows or secrets. Enabling a real production relay is a separate deployment task because it requires APNs provisioning and a managed service.

The editable row limit defaults to 50,000 and accepts values from 1 to 1,000,000. Values above 50,000 show a mobile-performance warning and use the editable Data read protection window, which defaults to 60 seconds, but the explicit configured limit remains effective. When Limit number of rows is Off, Cifru still applies a 50,000-row internal device ceiling. A read that exceeds its safety window, or an unbounded read that reaches that ceiling, is stopped before rows are cached or rendered and shows an actionable, localized message. The message distinguishes a live read from a cache read and reports the applied time limit, measured elapsed time and overrun, and configured row limit when available. The user can adjust Settings > Data sources > Data read protection, reduce the read with a date period/filter/row limit, or retry only that attempt with 120, 300, or 600 seconds. A controlled retry does not permanently change Settings.

Troubleshooting

Step-By-Step Examples

Example 1: SQL Server Customer Invoices With Details

1. Go to Sources > Add sources > Databases > SQL Server.
2. Open the new source. Fill Host, Port, Database / service, Username, Password, TLS. Use a read-only SQL user.
3. For new SQL Server sources, Trust server certificate is on by default because many private company servers use internal certificates. Keep it on only when the server is controlled by the user; otherwise prefer a valid public certificate.
4. Tap Save or Check connection. Both save the current settings and run a connection test. Wait for OK.
5. Go to Build > Home screens > Choose source and table/path and choose the tested SQL source.
6. Tap Browse tables. A modal opens over the assistant. Use the search field or table list to choose the invoice table/view. The selected SQL object fills Table/view to read directly and is displayed once as schema.table, for example dbo.accesex_facturi_clienti.
7. Tap Save selection & preview rows.
8. In Choose fields, set friendly labels such as Invoice number, Customer, Date, Total, Store. Set Type Date for invoice date and Number for totals.
9. Optionally assign semantic meanings such as Invoice ID, Customer ID, Store/Location, or Date. These labels help formatting and later suggestions; they do not create a relationship by themselves.
10. In Add to Home, name the button Customer invoices and tap Add button to Home.
11. In the Customer invoices Home screen, keep Sort set to the invoice date field descending and set Max rows to a reasonable value such as 100, 500, or 1000. For generated SQL reads, Cifru applies the date sort before the row limit, so the app fetches the latest invoices instead of an arbitrary set.
12. Create or configure a second list for invoice lines. Preview it and map Invoice ID, Product ID, EAN/Barcode, Quantity, Price.
13. Return to the Customer invoices Home screen. Tap Add guided Details or Details / row action > Guided Details.
14. Choose invoice lines as Details list/table. Match parent invoice_id to child invoice_id. Use Suggest fields automatically and check matching rate.
15. Save. Opening an invoice row should now show a Details button with matching invoice lines.

Example 2: Product Enrichment From WooCommerce

1. Add the WooCommerce source with Store URL, Consumer key, and Consumer secret.
2. Check connection.
3. Go to Build > Home screens > Choose source and table/path and create a Products button from known store data or an API path.
4. Map product ID, SKU, EAN/Barcode if available, product name, image URL, price, stock status.
5. On an invoice-lines list, optionally identify EAN/Barcode or SKU by its semantic meaning so Cifru can suggest a likely candidate.
6. For one product match per invoice line, use Build > Home screens / buttons > select invoice lines screen > Fields from other lists. Choose the enriching source/list, the concrete EAN/SKU field in the current screen, and the equivalent concrete field in the selected source. Review the match rate before adding product name, image URL, price, or stock status to the same card.
7. If the product should open a separate product screen, use a row button named Product with Show matching details.

Example 3: FTP CSV Feed Dashboard

1. Go to Sources > Add sources > Data feeds > FTP file.
2. Fill FTP host, Port, Username, Password, Remote file path, and File format CSV or AUTO.
3. Check connection.
4. Go to Build > Home screens > Choose source and table/path, choose/preview the file, map fields, and create a Home button. For XLSX files, tap Browse sheets and select the sheet that should become the list.
5. Set list Loading to Cache, Auto refresh cache On, Every 15 or 60 minutes depending on feed update frequency.
6. Add widgets such as Count, Sum, or Top list using filters and sort rules.

AI Configurator

Structure is not business correctness. A read-only SQL check can confirm real output fields without running an expensive report. It cannot decide whether you intended only products present in a warehouse or all products including those without stock. Use the optional real-data preview for that review, and add explicit instructions when regenerating. Preview rows remain local and are not sent to the AI provider.

SQL admission distinguishes grouped expressions such as WHERE (...), CASE WHEN (...) and TOP (5) from function calls. Unverified routines, writes and external execution remain blocked. Rejection diagnostics distinguish unsupported syntax, an unverified routine and outer ordering that belongs in Studio; they contain no query text or business values. Explicit requests for no Details also override a preceding request to reuse another screen layout.

Path: open Build, then tap the visible AI Configurator text action in the upper-right toolbar. This screen lets a user describe a dashboard in normal language. The same pulsing required-step cue used by the manual button builder guides the user in natural top-to-bottom order: enter the request, review the data-source choice when several sources are available, review or optionally enter the application/system name, then use Generate draft. Only the current step pulses; this is guidance and never silently changes the selected source or invents a system name. If the assistant is disabled, or an external provider is selected without a saved API key, this toolbar action opens AI Configurator settings directly so the user can enable and complete setup first. The selected provider returns only declarative JSON. Generate draft automatically discovers concrete schema, compiles mandatory main/Details/lookup topology locally, validates the JSON, runs bounded read-only functional tests through the real connectors, performs at most one safe functional repair-and-retest pass when needed, and then shows the final JSON/dashboard preview. AI can still omit or misinterpret a requirement, so the user must review the preview and tests and still decides whether to tap Apply configuration. While generation is active, the red Stop control also displays a monospaced elapsed-time counter; it is elapsed time, not a simulated completion percentage. The active job is owned above the temporary SwiftUI screen, so a phone-call interruption, App Lock presentation, or navigation rebuild does not cancel it merely because that screen was reconstructed. iOS background time remains finite: if the operating system terminates the process, Cifru records only that an anonymous run was interrupted, applies nothing, stores no prompt or credential in that marker, and offers a safe retry when reopened.

Community and configuration library

Path: Build → Community and configuration library. Library contains only public-catalog actions: explore approved packages or select one or more of the user's Home-button trees and submit them for moderation. Direct transfer and backup is separate: it imports or exports a .cifruconfig attachment through Mail, AirDrop, or Files without publishing anything. A shared tree includes its required Details/sub-buttons, lists, relations, enrichments, related widgets, and used common fields. Application/system name, configuration language, and country coverage are mandatory. Multiple countries are supported; ALL is available only for configurations that include English.

Every import makes each Home tree an explicit selectable checkbox, reports how many are selected, and offers Select all / Deselect all. The full downloaded JSON and the exact selected subset are shown separately. The user maps symbolic source slots to already configured local sources. For a mapped SQL source, Community compatibility compiles either the complete read-only custom query or an exact zero-row SELECT against the selected table/view, then validates the returned schema and mapped columns without materializing business rows. This keeps complex views responsive while still confirming the object, read permission, query shape, and expected fields. Non-SQL feeds and APIs retain a tiny bounded read because they do not expose a portable database-style result schema. The mapped source itself must already have passed the normal source setup test, including a bounded real preview. Compatibility failures identify the affected list/object and missing fields instead of exposing a generic driver error. Apply remains visibly locked with a reason until selection, plan, mapping, and read-only tests pass. Custom-query components cannot be imported in Free or Starter regardless of whether the file came from Community, Mail, AirDrop, or Files. Packages never carry source credentials, private endpoints, cached rows, or subscription rights. The last successful import can be undone from the Community screen.

The optional Community account is needed only for publishing, reviews, and contribution management. Cifru reads the public service health status and displays only social providers actually configured by the Community operator. Mobile authorization uses a browser session, state and PKCE; the resulting Cifru Community token is stored in Keychain. Browsing, package download, direct import, and private export remain available when no login provider is active. Publishing can include up to eight optional screenshots selected through the system photo picker. Cifru normalizes them to JPEG on device; the service validates dimensions and format, rewrites them without embedded metadata, creates thumbnails, and publishes them only after moderation. Configuration languages and countries use compact searchable multi-select screens; country code ALL remains mutually exclusive with individual countries.

Public library app-entry hooks

When the user chooses Explore the online library, Cifru opens the public Community URL with three presentation-only query parameters: entry=cifru_app, platform=ios|android, and lang=<effective BCP-47 interface language>. The Community site uses them only to select the app-oriented layout, platform wording, and initial language. If the app language is Automatic, Cifru resolves the effective system language and region rather than sending the literal value automatic; if it cannot resolve a language, it falls back to en. Existing legitimate URL parameters and fragments are preserved, while duplicate entry, platform, or lang keys are replaced with one final value. These hooks contain no account, email, user or device identifier, subscription or plan, explicit IP value, source configuration, business data, or credential, and they are not used for advertising, profiling, fingerprinting, or individual tracking.

The normal flow is designed for non-programmers. Tap one of the request examples or write a short request, leave source choice on Automatically choose relevant sources, then generate. During generation, the same action becomes Stop generation and cancels the active provider/check pipeline without deleting the previous draft. Cifru shows only the real current operational phase, not model chain-of-thought. Regenerate keeps one previous draft that can be restored. The result is human-first: visual Home cards, nested Details and widgets appear before an exact change summary; technical topology and raw JSON are collapsed until opened. Apply has a separate confirmation and a successful apply can be reversed once with Undo last AI apply.

Apple On-Device has a smaller practical context budget than external providers. When necessary, Cifru sends it a relevance-ranked subset that keeps the strongest live main/detail candidates and relation/enrichment fields for every independently requested flow. The UI shows both full prepared counts and focused counts. Local graph completion and validation always use the full discovered schema. External BYO-key providers normally receive one request, but malformed output or one repair after a real functional test may require an additional provider request and may incur provider charges.

For best results, the user should write which application, database, service, or system they want to integrate, which Cifru data source/list should be used if the AI cannot infer it, and which Home buttons, row Details buttons, filters, widgets, or exports they want. If External AI Documentation Research is enabled and approved, the external provider searches official producer/vendor manuals first. Cifru also supplies generic implementation notes describing how its installed SQL, feed/file, REST/GraphQL/OData, ecommerce, Details, filtering, limiting, and enrichment components actually behave. The AI must cross-check every proposed object and field against exact safe metadata and list manual titles/URLs and uncertainty under Documentation used and assumptions. The initial request contains no source rows. An optional automatic-repair request may include only the bounded identifier sample described in the privacy section; it never includes credentials, names/contact data, invoice contents, descriptions, prices, totals, stock, quantities, or private URLs.

If the user has added and fully verified a source but has not manually created a list/table, AI Configurator can still start. Cifru discovers schema locally: SQL table/view names and column names/types through fixed read-only catalog queries, and feed/API/XML field or tag structure through a bounded local preview. MySQL/MariaDB discovery tries SHOW TABLES, SHOW FULL TABLES, and information_schema.tables; columns use SHOW COLUMNS, DESCRIBE, then information_schema.columns. A transient NIO channel closure is retried once with a fresh connection. HTTP/FTP transport interruptions are also retried once when safe. Object names are ranked separately for each requested flow. Cifru contains no executable profiles keyed by ERP, ecommerce product, application, table, endpoint, installation prefix, or field name. Public manuals can improve the external provider's interpretation, but every candidate still comes from the live source. A connection is only a profile, not a readable list: Cifru never sends generic _source_setup metadata to AI as a usable list object. It resolves the selected connection to a concrete table, view, endpoint, sheet, feed, file, or vendor object and requires the returned list to reference that object. If the concrete structure cannot be read, generation stops before calling AI and distinguishes transport interruption, permission denial, authentication, TLS, invalid response, and missing-object cases where possible. Cifru also blocks an AI-created SQL list whose table/view target is empty. If the user selects one primary source, Cifru can include verified auxiliary lookup sources such as feeds, files, object storage, REST/GraphQL/OData APIs, and ecommerce connectors. Initial generation sends schema metadata only. Full row/feed contents, URLs, hosts, credentials, tokens, connection strings, invoices, customers, prices, stock, and quantities are never sent. One later automatic repair may include only the optional bounded identifier sample described below.

After an AI provider returns JSON, Cifru sanitizes it and tries to repair common draft mistakes before validation. It first reconciles each list with a concrete discovered object using the list's requested role (main, Details, lookup/enrichment), dashboard/list/relation titles, configured source alias and root connection, exact field coverage, and the provider's declared object references. This prevents a semantically different but readable table from replacing the requested business object merely because both expose fields such as id_document. Import, staging, queue, buffer, and write-back objects are strongly rejected as automatic substitutes unless the user explicitly asks to inspect that exact read-only surface. If top-level dataSources and list dataSourceId values contradict each other, the repaired graph is made internally consistent before testing. The generic provider repair runs before Cifru's deterministic request completion, so it cannot later reverse a locally verified Details or enrichment direction. When the user explicitly selected a concrete table, endpoint, sheet, feed object, or configured list, that exact object remains the visible primary list before Cifru adds Details or cross-source fields; a documented integration profile can still replace it when the prompt explicitly requests that documented business object. Examples of other repairs: if the AI invents generic fields such as title, status, amount, or valoare, Cifru maps them to the closest fields in the discovered schema or removes them if no safe match exists. If a widget points to a list created in the same draft, Cifru accepts that list reference. If an enrichment is backwards, such as an XML feed trying to enrich invoice lines, Cifru can flip it so the visible invoice-line card is enriched from the feed. If an AI provider mistakenly uses a raw source ID as parentListId or childListId in a relation/enrichment, Cifru creates an intermediate lookup list for that source and rewrites the relation/enrichment to the generated list ID. Feed/API/XML display and enrichment fields must exist in the concrete detected schema. Guessed fields such as LinkEmag, competitorUrl, imageUrl, EAN, or SKU are removed when that exact source did not expose them.

Provider completion is checked before any JSON fragment is accepted. If OpenAI, Claude, or Gemini reports an incomplete/max-token response, Cifru ignores the partial text and makes at most one compact retry. The retry uses the original request and the same safe metadata; it does not echo the malformed partial JSON. The same retry is used when a provider claims completion but returns an unclosed or non-object JSON document. If the second response is still malformed, Cifru discards both responses, shows a clear error, and leaves Apply disabled. Truncated JSON is never sent into the normal mapping-repair pass.

A complete JSON response that merges independent requests, chooses the wrong live object, omits a Details edge, reverses a relation, or omits a requested enrichment does not consume a second provider request. Before object binding, Cifru turns numbered and natural-language clauses into a vendor-neutral intent graph. Each business flow receives its own Home role; inherited phrases such as “la fel” keep the requested Details shape without copying the previous business object. Cifru then deterministically rebuilds the graph from concrete objects and compatible semantic field aliases already discovered on the device. The reconstructed graph is validated for both technical readability and requested-flow coverage and must still pass the production-connector dry-run.

Finding readable tables is not enough: every requested flow must have an independently matched Home screen, every requested Details action must use a compatible child object and real relation fields, and every requested opening filter must exist on that flow. A global dashboard title is never used to bind every list, and a relation for one parent/child pair cannot overwrite another sub-button. If the concrete graph cannot be built from locally discovered safe metadata, generation stops and explains the missing flow instead of silently returning fewer buttons.

Enrichment lookups are chosen conservatively and are transport-neutral. A per-item lookup may come from any configured read-only source, including SQL Server, MySQL/MariaDB, PostgreSQL, Oracle, an ecommerce connector, API, feed, FTP/object storage, or local file, when its concrete item identity matches the detail rows. Cifru prefers exact or semantically compatible pairs such as cod_produs to EAN, barcode to ean_code, or matching SKU/product IDs. A wide business table joined only through a header/document identifier is a master-detail relation, not a lookup, and is not attached as card enrichment. When the user asked for extra card fields but no configured source exposes a compatible lookup schema, Cifru still generates the main screen and Details, explains the missing lookup in a warning, and lets the user connect or map the lookup source later, instead of failing the whole generation.

For every flow, Cifru removes a conflicting provider-proposed enrichment between the selected detail and lookup lists, then creates one locally validated edge in the visible-detail-to-lookup direction. This prevents a reversed or duplicated AI edge from leaving a valid field name attached to the wrong source. Verification is tied to exact source identities, so two configured instances of the same application cannot invalidate or redirect each other's dashboard.

Required topology is not delegated entirely to the AI provider. After parsing the provider's declarative JSON, Cifru interprets common non-technical requests such as "when I open one, show what it contains", "put the products inside each order", "show the conversation for each ticket", or "match the picture from the other feed by product code". It then completes a missing main-to-Details relation or cross-source enrichment locally, using only exact discovered fields, compatible semantic roles, and built-in Cifru components. This works the same way for databases, ecommerce APIs, REST/GraphQL/OData, feeds, FTP/object storage, and local files. It can match vendor-neutral identifiers such as ticket_id, project_id, budget_id, PO_ID, UUIDs, documented ID pairs, and EAN/SKU families. A plain ambiguous id is not accepted as a fallback unless the local metadata gives it a compatible semantic role.

The original user request remains the semantic authority throughout automatic repair. Cifru sends a separate technical repair prompt to the provider, but it does not rebuild intent from that repair text, a global dashboard title, or a previously wrong draft. Requested main/detail roles and their Details edges are reconstructed locally after every provider response. The final check compares compatible fields actually discovered in the installation; safe aliases may match when local metadata assigns the same semantic identity. Provider output cannot remove, merge, or redirect a requested flow.

Cifru also normalizes requested scope before preview. A provider-created relation is removed when the user did not ask for Details; an enrichment is removed when the user did not ask to combine sources; and unrequested or duplicate widget types are removed. Short intent words are matched as complete words, so a request containing categorie is not misread as the Romanian count word cate. Common Romanian singular/plural forms such as imagine, imagini, and imaginile are recognized, while explicit refusals such as "nu vreau indicator" take priority over positive keywords elsewhere in the sentence. Phrases such as "show the total field on the card" do not create a metric widget, and "show the existing link column" does not create a cross-source mapping. The resulting graph is validated again and then sent through the local read-only dry-run. If the user's intent is still ambiguous or no compatible concrete objects/fields exist, Cifru stops with a focused setup message instead of guessing.

Cifru then runs an automatic local dry-run through the same production connectors used by the generated screens. It tests every list/widget with small row limits, tests Details against representative parent rows, and tests cross-source enrichments using the same common-field normalization rules used at runtime. Direct database connectors group candidate equality values for the same child field as read-only OR alternatives and apply the row limit after filtering. Feed/file/custom API enrichments use a bounded local lookup scan where portable server-side equality filtering is unavailable; OData and supported ecommerce APIs may push compatible filters to the service. If a schema, field, filter, relation, or enrichment is repairable, Cifru sends one correction request and retests the result. The repair request contains the previous declarative JSON, safe diagnostics, and, only when enabled and necessary, at most one identifier-only mapping sample per relevant object. Authentication, permission, network, TLS, and timeout errors are shown directly and are not sent to AI for repair.

Provider testing is deliberately separate from connector testing. On July 11, 2026, the synthetic OpenAI evaluation ran 68 novice-style prompts across all 17 Cifru source kinds with gpt-5-mini-2025-08-07. All 68 responses contained the required list/Details/enrichment/widget topology, but 30 raw responses also contained at least one unrequested relation, enrichment, or widget. This is why local scope normalization is mandatory. These synthetic provider tests do not claim that every third-party server, permission model, plugin, or schema is live-compatible; the generated draft must still pass the on-device production-connector dry-run before Apply becomes available.

The AI JSON can describe lists, homeScreens, relations, enrichments, and widgets. This allows a natural prompt such as: "For my ERP, create latest supplier invoices, add Details for invoice lines, and show product/feed data on invoice lines by matching EAN." Cifru maps this to native Lists, Home buttons, row Details buttons, and card enrichment fields after validation and user confirmation. For XML competitor feeds with fields such as EAN, LinkDedeman, and LinkMathaus, the expected setup is invoice lines as the displayed parent list, the XML feed as the lookup child list, a common product/EAN field as the match, and Link* fields as display fields.

Public manuals are deliberately not copied into built-in completion rules. The same compiler handles an ERP, ecommerce platform, ticketing system, public API, spreadsheet, feed, or an unknown internal database. Research may tell the external provider what a business concept usually means and which public object names to search for, but Cifru selects only objects and fields present in the configured source. This avoids a fix for one documented application becoming a hidden exception that makes the other flows less reliable.

In the 1.1 SQL preview flow, a slow or cancelled optional read does not undo a successful structure check. If the read instead detects changed columns or lost access, Cifru revokes that check and asks you to regenerate before applying. The exact source, SQL and field configuration must still match the locally checked draft; an ordinary cache timestamp update does not invalidate it. Preview values stay on the device.

Allowed AI JSON Shape

The AI should return a single JSON object, not Markdown. Cifru expects this shape:

• Allowed widget types: metric, table, line_chart, bar_chart, alert_list. Line/bar charts require exactly one groupBy X field and count or numeric sum. pie_chart is rejected as unsupported in this version.
• Allowed actions: refresh_data, open_detail_view, apply_filter, clear_filter, export_view, navigate_to_dashboard, only when the app already has that behavior.
• Allowed aggregations: count, sum, average, min, max, and latest/current for one sorted current value, depending on the field type and source capability.
• SQL, if present in a future declarative draft, must be read-only SELECT/WITH. Cifru blocks INSERT, UPDATE, DELETE, DROP, ALTER, EXEC, TRUNCATE, MERGE, CREATE, GRANT, and REVOKE.
• Cifru blocks JSON keys suggesting executable behavior: code, script, eval, plugin, executable, runtime, module, and downloadedCode.

Provider Choices

Both AI entry screens show provider readiness before generation. Apple On-Device and Mock / Local Templates do not require an API key and cannot browse the web. OpenAI, Claude, and Gemini are external providers and require a user-supplied key stored in Keychain; when the selected external provider has no saved key, Cifru shows a direct link to AI settings.

For OpenAI, Cifru parses the raw Responses API output defensively. It does not assume that text is always located at output[0].content[0].text, because the response can include reasoning, web-search, or other items before the final message. Cifru reads supported text/JSON output shapes and reports clearer errors for incomplete responses or output-limit issues.

Safe Metadata Sent To AI

Cifru constructs SafeDataSourceMetadata from configured lists. It may include:

• internal list/source id;
• display name;
• source type such as sql_readonly, rest_api, ftp_feed, local_feed, vendor_api, or readonly_feed;
• field names, field types, nullable flag, semantic/common field role;
• allowed operators, aggregations, widgets, actions, and capabilities.

Initial generation does not include source rows. If minimal mapping samples are enabled and automatic repair needs value-shape evidence, Cifru may include at most one reduced row per relevant object, limited to 12 bounded identifier-like fields such as document IDs, product codes, EAN/barcodes, or SKUs. Local filtering excludes credentials, secrets, tokens, URLs, hosts, usernames, customer/supplier/contact/name/address fields, descriptions/notes, prices, totals, stock, quantities, exports, and private/internal documentation URLs. Sample values are never copied into the saved declarative configuration, warnings, logs, or analytics.

External AI Help Chat And Copyable Prompt

The empty Home screen, Start guide, Help, AI Configurator, and the "Ask an external AI with Cifru" Siri/App Shortcut identify this surface separately from Cifru's built-in AI Configurator. If no OpenAI, Claude, or Gemini key is stored, it shows the localized copyable prompt below. If at least one external key is stored, Help opens a conversational assistant using the same provider model, base URL, and Keychain credential already configured in Cifru.

The external Help chat keeps a bounded transcript locally with iOS complete file protection and offers a New conversation action that deletes it. Every request starts from a vendor-neutral map of the controls and navigation paths implemented in the installed Cifru binary, plus generic recipes for authentication, latest-value screens, Details, cross-source matching, cache, and external widgets. It also retrieves relevant sections from a locally cached/indexed copy of the complete public Cifru HTML guide. Public web-manual search is disabled by default and is used only after the user explicitly enables it; public manuals supplement the installed UI map and cannot invent a control that Cifru does not contain. Only a bounded recent message window, safe source metadata, and relevant public documentation excerpts are sent after first-use confirmation. Common API keys, bearer tokens, password/connection-string fragments, and private/internal URLs are redacted locally before transmission. The chat provides explanations only: it cannot create, apply, or silently modify a dashboard. It displays operational status such as reading documentation or waiting for the provider and never exposes hidden model chain-of-thought.

The copyable prompt is localized by app language and points to the HTML documentation. The English version is:

Privacy, Legal, And Responsibility

The user chooses and controls their own sources. The user is responsible for credentials, permissions, third-party service terms, source availability, source-side access controls, and decisions made from displayed data. Cifru is not a backup system, accounting authority, audit system, legal system, medical system, financial trading system, or source of truth.

Use read-only accounts, least-privilege permissions, TLS/HTTPS, VPN or private network access where appropriate, and independent source-side logging for important systems.