Look around before signing in: the stores this installation knows, which of them is active, whether Melbis Shop is running and on which store, and where the documentation starts. Writes nothing, asks the shop nothing, costs nothing - call it again whenever the person may have switched store in the program.

Sign in to the active store - the one the program opened last, which session_init marks. Takes no arguments and cannot take a password: you sign in as the person at the keyboard, and the running program hands the pair over itself, or the settings it stored. If it answers NO_SETTINGS, the owner starts the program or ticks password keeping - a password has no place in this chat.

Everything the store is made of: modules with their cache flags, template views, statics, images and fonts, folders, and the server journals (log lines: apache, nginx, the engine itself - with date and size). path narrows it down to one branch.

Function signatures of the unit files - what a module may call.

Columns, keys and storage engine of a table. Without name - the list of the tables. Accepts the real name (ms_store) or the bare one (store). A gen line means the table needs a generated id before an INSERT.

Parameters of config.json. Secret values come back as - never ask for the real ones.

Load a php file (root script or module) with its manifest.

Save an existing php file. The body comes either as content, or as file - a path on this machine, and then it travels byte for byte and you never retype it. For a module pass manifest to rewrite its .json - all of it but the table list: the engine learns that from the queries the module runs, and a save keeps only the lines you switched off (bare names: log=0).

Create a php file by the same path load and save speak. units/.php makes a module - its .json and a view folder in every template set come with it; any other path makes a root script beside index.php.

Rename a php file: path is what it is called now, new_path what it becomes. Both stay of one kind - a module (units/...) stays a module, a root script a root script.

Delete a php file by its path. For a module (units/.php) the .json and its view folders in the template sets go too.

Load a template view .htm (templates//units//main.htm). Read before editing - save overwrites.

Save an existing template view .htm. The body comes either as content, or as file - a path on this machine, and then it travels byte for byte.

Create a template view by the same path load and save speak: templates//units//.htm. The module folder is created if it is missing.

Rename a template view: path is what it is called now, new_path what it becomes - inside the same module folder, only the file name changes.

Delete a template view by its path.

Load a static file, css or js (templates//statics/...). Read before editing - save overwrites.

Download ONE file of the store, any tree, byte for byte: written to file on this machine, never entering the answer. The way to take a journal of core/log whole - the plain load answers with its last megabyte - and anything else too big or too exact for an answer.

Save an existing static file (css/js). The body comes either as content, or as file - a path on this machine, and then it travels byte for byte.

Create an empty static file by the same path load and save speak.

Rename or move a static file: path is what it is called now, new_path what it becomes - the same folder with a new name renames, another folder (statics or images) with the same name moves. The bundle descriptors follow it.

Delete a static file by its path.

Create a statics folder. path is the whole new folder; its parent must exist.

Rename or move a statics folder: the same parent with a new name renames, another parent with the same name moves. The bundle descriptors of the files inside follow it, but the built statics/bundle.* are NOT rebuilt: the answer says how many files were involved, and the owner re-saves those bundles in the program.

Delete a statics folder WITH everything inside it, recursively, bundle descriptors included. No undo - warn the owner first.

Load a file of the images tree - the design of a template: picture, font, icon, NOT a file of a product (those live in engine_files_*). By its tree path (templates//images/...). Always saved locally under mcp/melbis/, png/jpeg/gif/webp additionally come back inline, svg as text. Never reads the local copy: every call goes to the server and overwrites it.

Upload a file of the images tree: path is the full target, folder and name at once. The body comes as file - a path on this machine - or as content, text for svg. An existing target is overwritten only with overwrite=true - files here have no version history.

Rename or move a file of the images tree: path is what it is called now, new_path what it becomes - the same folder with a new name renames, another folder with the same name moves.

Delete a file of the images tree by its path. No undo and no version history - warn the owner first.

Create an images folder. path is the whole new folder; its parent must exist.

Rename or move an images folder: the same parent with a new name renames, another parent with the same name moves.

Delete an images folder WITH everything inside it, recursively. No undo - warn the owner first.

Create a template group.

Rename a template group.

Delete a template group.

Attach local files to store elements. entity is the element table (store, info, info_value, brand, topic, key_value, lang, field, advert_text, order_option, order_option_value, web_key, web_key_value), elem_id the row that owns the file, file a local path. kind_key defaults to kBase and is checked against the key_value registry. The engine does the rest: id, name, folder, row. Big lists are sent in several packs by the MaxFileSize of Shop.ini.

Download element files into /files, the same layout the program keeps. Give id for one row or elem_id for every file of an element. Answers with the manifest: id, kind_key, real_name, pos, size and state - ok, missing, or skipped when the pack hit the size limit (ask again by id).

Delete rows of element files. The file itself stays on the server disk - there is no delete for it anywhere in the product; the owner reclaims space by running the idle-files audit module. No undo on the row: warn first.

Read data. pool is a list of steps, each {"do":"select","sql":"..."} with optional params and name. A value belongs in params and not in the text of the sql: write :NAME in the sql, upper case, and put the value in params under that name in any case you like. That is what keeps a quote, an apostrophe or an alphabet of its own from breaking the query. Table names take {DBNICK}_ or the real nick, both work. Values come back whole - no truncation, no column limit - so ask for the rows you need, not for a million. A step over 5000 rows is refused unless it carries "big":true. A step that carries "file" keeps its rows there instead of in the answer - one json object to a line, at any size, path absolute or off the store folder: that is how a snapshot of what you are about to change is taken, and it belongs in your own folder, not under mcp/melbis, which is wiped without warning. The pool of this command also takes the dependent step (table, and ids when you have them): what hangs on that table, and how many rows point at those ids. It only reads, so it belongs here as much as a select. A pool too big to write out is built by a script and given as pool_file instead of pool.

Run a pool of steps in ONE database connection, which is the only way a temporary table or LAST_INSERT_ID survives between them. Steps: lock (our table registry, not the DBMS), unlock, generate (id from the generator), select, modify (any sql), insert (table + rows as one multi-row INSERT of at most 65535 values, rows times columns - more rows go as several inserts), change (mark tables so the storefront cache refreshes). Trees (topic, info and any table with tindex/tlevel/absindex) are shaped ONLY by the tree steps - never by raw sql: tree_add (table, parent_id; 0 = top level; answers the new id), tree_move (table, id, parent_id), tree_up / tree_down (table, id), tree_remove (table, id; deletes the whole subtree). A tree step rebuilds the indexes and marks its table itself; the new row is bare, so set its fields with a following modify by the lent id. A new topic or info node is visible to the admin only until you insert its rights rows. Before a delete ask dependent (table, and ids when you have them): what hangs on that table and, with ids, how many rows point at them. After deletions run clear_dependent (table): it sweeps the rows left pointing nowhere and names the busy tables it skipped. Values go in params: :NAME in the sql, upper case, the value under that name in params. A named step lends its value to the next ones as @name, in params too. Nothing is guessed: tables you touched with raw sql are refreshed only by the change step, so put it in. A failed step stops the pool and the answer says which one and why; whatever the pool locked it releases itself. Announce data changes to the owner first, and ask whether to take the tables into work (a lock step) for the time of the change - do not decide that alone. Keep the locked stretch short: read and compute before the pool, not inside it. A pool too big to write out is built by a script and given as pool_file instead of pool.

Tables currently taken into work: who holds each one, by which operation, since when. MELBIS SYSTEM + MELBIS_SYSTEM means the storefront parser locked it from a script; a real user with MELBIS_SYSTEM means a lock taken outside an operation - a manual one from the program, or one of your own from a lock step or from adding a file. Check this before working with table data, reading included: a held table is being changed right now, so warn your counterpart about what you find.

Release the locks YOU left behind: rows of oper_block under your own login and outside any operation - what a tool of the store took and died before letting go. A lock of the storefront, of another person, or of an open form of the program (it names its operation) stays where it is. Without tables every stuck row of yours goes, with them only the ones named. Look at engine_db_locks first: a table taken a second ago may belong to a call still running.

Substring search over the server files: unit code and its views, root scripts and .htaccess, css and js of every template set. Manifests, core and images are out of it.

Saved-version history of a file. before is a datetime cursor (version <= before); page down with the last row's value.

Content of one saved version by id.

Clear a cache level: cache|trick|smart|static|unit_cache|unit_trick|unit_smart. unit scopes the unit_* levels. Saving a module already drops its own cache, and saving a library drops the cache of everyone using it, so this is for the manual and the wholesale clears.

What is in your memory of THIS store: every note with its number, category, kind, description, size and time - the texts are asked for separately. Read it at the start of a session: every kCritical note is loaded before any work, the rest when a job needs them. It lists the notes of everyone, of your groups and your own, in that order, the first two marked. Past 100 notes, tell the user it is time to keep how the project works in a charter of the store, not in notes.

Read notes by their numbers, several at once - memory_list numbers every note. A session starts with every kCritical note, and every other command is refused until all of them are loaded; one of them may name others to read with it - find their numbers in the list. Each note comes marked: your own, a group's, everyone's; a number you cannot see comes back in missed.

Write a note of your own - ONLY after the user agreed to it: say the note first, with its name, category and kind, and write it when they say yes; what they did not agree to may go into your own folder, which can vanish. With id - the number memory_list shows - that note is changed, without it a new one is written; what you leave out keeps its old value. Worth offering is what you learned about THIS store and could not read out of the code: a decision and why it was taken, a convention the owner insists on while it takes shape, a trap that cost you an hour. Not what the code already says - that is what the map and the files are for. Notes are reviewed with the user and cleared: a settled rule of the project belongs in the charter of the store. kind_key says how the note binds: kCritical is read before any work, kDirect is an order of the user, kSkill is how to work with them, kDefault the rest. Where two disagree the order is the kCritical, kDirect and kSkill of everyone, then of a group, then your own, then every other note. The notes of groups and of everyone are the administrator's and are not written here. While the program holds the memory in its window, a write is refused and the note is not kept: offer the user to put it into the scheduler, if its AI-tool is granted to you. This table - not the host's own memory - is where anything about this store or its people's rules belongs: host memory stays on this machine, and the owner never sees it.

Forget a note of your own by its id, as memory_list numbers it: one that turned out to be wrong, or one the user agreed to drop at a review.

What THIS store can do beyond the engine: tools its owner wrote for you - add a product the way this shop adds one, close an order the way this shop closes it. Without a unit it lists them all - session_connect says how many; name a unit and it answers that one tool in full - every command with every field it takes, which is what you fill a call from.

Run one command of a tool of this store - the working way to do a job the owner already provided for. Say the unit from tool_list, the command, and its parameters as that tool declares them. Not the same as shop_run: that one runs a module YOU wrote, past the storefront, and returns what it printed; this one calls a function the shop wrote, and the store checks the registry before it runs.

Back up the AI tools of this store into one zip on this machine: the registry - the tree, every command, every field it takes - and the modules behind it with their manifests and the libraries they lean on. Grants are not in it. Keep the file, and when the tools are updated, unpack it and compare: index.json carries a sum per file, so you read only what actually differs.

Fetch a page of THIS store as a visitor sees it and save the HTML under mcp/melbis/pages/. Answers status, size, title and then the fragments matching find - or the head of the page when neither find nor debug is given - read the saved file for the rest. Mind two things: a save drops the cache of the module the file belongs to, its views included, and nothing else - the rest is cleared by hand; and this is markup, not a picture - how it LOOKS is still for the owner to say. debug=true adds the parser report: timings, SQL count, cache state.

Run a module of YOUR OWN on this store and read what it printed. This is for code you wrote yourself and want to try: a report over several tables, a check across the catalogue, a one-off fix with its own logic. For work the owner of the shop already provided for, use tool_run instead - that one has a registry row and a grant behind it, this one has nothing but the session key. The storefront runs the module exactly as it runs any module - same parser, same cache, same access to the data. Three conditions. The name starts with agent_ (the entry point runs nothing else); the module exists - create it with engine_php_add and write it with engine_php_save; and it is saved as an entry point, which is manifest ajax_load=1. The output is saved under mcp/melbis/runs/ and comes back here whole unless it is long.

Copy the code of THIS store onto this machine the way the program copies it: modules - the units, the templates and the root scripts; profiles - the picture profiles; database - a dump of it, which for a large store is a large file and travels whole. It arrives unpacked into a folder here, so you read the store as files instead of loading it one by one.