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.

Version: July 11, 2026. Developer / seller: Dumitru Ionut-Madalin Dumitru. Contact: madalin@madalin.org.

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. 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.

Home Button Assistant

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.

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 or widget action, where the user can choose a recipe, 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.

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.

The Create a screen or widget action offers three guided recipes: Home button with list, Home button with Details, and Widget with total, current value, or ranking. 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. 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.

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.

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. 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. Basic mode never requires SQL.

Lists Editor

Path: Build > Lists > select list.

Advanced Read-Only Queries (Pro)

Paths: Build > Create a screen or widget > 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 open the same editor and use the same validation/test rules. This expert feature is available only while Pro and Advanced mode are active. It works for a new or existing Home list and for a list opened by a per-card action.

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.

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. 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.

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. When it is disabled, the list opens immediately and those controls remain optional filters above the rows. 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. 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.

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 require an active verified StoreKit entitlement. After a successful verified purchase or transaction update, Cifru activates the verified plan immediately and then reconciles it with Transaction.currentEntitlements, so temporary App Store sandbox propagation delay does not keep the previous plan on screen. TestFlight purchases run in Apple's sandbox 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. Sources, lists, relations, pages, and widgets above the active plan limits are visibly locked and cannot test a connection, browse tables/endpoints, preview or read rows, refresh in the foreground or background, appear as usable Home content, publish external widget data, or be sent to the AI Configurator as usable metadata. Reactivating an eligible entitlement restores access to 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.
• Default external widget snapshot refresh request is 5 minutes, but iOS controls the exact timing.

Cache Guidance

The configured refresh interval means that data becomes due for refresh after that time; it is not an exact background timer. iOS decides when Cifru may run. The default iOS-managed mode catches up at every granted background opportunity and whenever the app becomes active. 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.

Even when Limit number of rows is Off, Cifru applies adaptive device protection. An unbounded or unusually high-limit read receives a 15-second safety window and an internal ceiling of 50,000 rows. A small, fast, or source-filtered result can still complete without an explicit row limit. A read that exceeds the safety window or reaches the ceiling is stopped before rows are cached or rendered and shows an actionable message. Select a date field and period, add a filter, or enable a smaller explicit row limit before retrying.

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

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. 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, then Cifru confirms direct-database object fields before bounded reads through the real connector. 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.

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.

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.