DEV Community: Serhii

Git worktrees as agent isolation: what broke, with the code

Serhii — Tue, 22 Sep 2026 15:52:03 +0000

Giving a coding agent its own git worktree has become the standard advice for letting it work without trampling your checkout. It's cheap, it's native to git, and it gives every task its own branch. I build VADD, a local dashboard that wraps Claude Code and Codex, and every objective there runs in its own worktree under ~/.vadd/worktrees/<projectId>/<objectiveId>.

The advice is right. But nobody mentions the part where it goes wrong, which is the part that matters when you automate it. Here's what broke for me, roughly in the order I hit it.

1. `git worktree remove` can succeed while the files stay on disk

This was the worst one because it lied.

My original teardown looked like the obvious thing:

await git(repo, ['worktree', 'remove', '--force', path])
await git(repo, ['worktree', 'prune'])

// post-condition: is it gone?
if ((await listWorktrees(repo)).includes(path)) throw new Error('still registered')

One day I checked disk usage and found about 1.7 GB across five directories under the worktrees root. Two of them came from a cleanup run that had reported 26/26 success.

What happened:

git worktree remove --force deletes the worktree's .git link file first, then recursively deletes the rest.
The recursive delete failed partway. The repo was a Laravel app, and an in-container composer install had written backend/vendor as root:root. My user can't unlink files in a directory it doesn't own.
git had already removed its admin entry. And the missing .git link file is exactly what causes git worktree prune to deregister a worktree.
So my post-condition asked git "is this worktree still registered?", git truthfully said no, and the function returned success while the directory stayed on disk.

Git-level success and filesystem-level success are two different facts. Check both:

const target = resolve(worktreePath)
if ((await listWorktrees(repoPath)).some((w) => resolve(w) === target)) {
  throw new GitError(`Worktree still registered after removal: ${worktreePath}`, 'EGIT')
}
if (existsSync(target)) {
  throw new GitError(
    `Worktree directory still on disk after removal: ${worktreePath}. ` +
      'Git has deregistered it, so nothing will retry this. Most likely it ' +
      'holds files this user cannot unlink (a root-owned vendor/ or ' +
      'node_modules/ written by an in-container install).',
    'EGIT',
  )
}

You can reproduce it without root. Unlinking a file is authorised by the directory that contains it, not by the file itself:

mkdir -p wt/locked && touch wt/locked/f && chmod 555 wt/locked
# now `git worktree remove --force` on wt fails halfway, and prune hides it

A follow-up lesson: git worktree list can't show you this kind of leak at all, because git no longer knows the directory exists. My UI listed worktrees from git and couldn't display the leak it was meant to prevent. The fix was to also readdir the worktrees root and report anything no database row or git entry claims.

2. A fresh worktree can't run the project's tests

An agent that's asked to work test-first needs to run the tests. A new worktree has no node_modules, no vendor, no .env: only tracked files.

Symlinking the root node_modules isn't enough with pnpm workspaces. I tried it on my own repo and still got Cannot find package 'zod', because pnpm resolves through per-package node_modules too.

What I ended up with is a per-repo setup step in .vadd/config.json that runs once, when the worktree is created. It used to run before the first verification, and that was too late, since the agent needs to run tests in its very first task.

{
  "verify": {
    "setup": [{ "id": "deps", "run": "pnpm install --frozen-lockfile" }],
    "commands": [{ "id": "test", "run": "pnpm test", "required": true }]
  }
}

If setup fails, the objective stops in setup_failed with the log kept as evidence, instead of letting the agent try to work in a worktree that can't build.

3. Hard-linking dependencies silently skips files

For big PHP vendor/ directories I tried cp -al (hard-link copy) to avoid reinstalling. It looked like it worked. It hadn't.

With fs.protected_hardlinks=1, which is the default on most distros, the kernel refuses to hard-link a file you don't own. cp -al doesn't fail loudly when that happens. About 1,800 root-owned files in vendor/ were just missing, and the worktree looked complete.

If you do this, follow the link pass with a copy pass that fills in the gaps:

cp -al  "$MAIN/backend/vendor" "$WT/backend/vendor"
cp -a --no-clobber "$MAIN/backend/vendor/." "$WT/backend/vendor/"

A broader point: hard-linking root-owned trees into every worktree is also how you create the un-removable directories from trap #1. Link only what the commands actually need, and prove the need by running the commands without it first.

4. `docker compose exec` works on the wrong checkout

Many projects bind-mount the main checkout into their containers. An agent working in a worktree that runs docker compose exec app php artisan test is testing code it didn't write, from the main checkout, and gets a result that has nothing to do with its changes.

There's no clever fix for this inside git. What worked for me was a setup step that points a copied .env at the containers' host-exposed ports (database, cache), so the test runner runs on the host inside the worktree, and Docker only provides services, not the code.

5. Protected files leaked into the squash commit

That setup step had a side effect. It rewrote a tracked file (backend/.env.testing) to remap ports. The agent's checkpoint commits use git add -A, so the change went into every checkpoint, and the final squash would have carried it onto the branch and broken every other developer's Docker setup.

I already had a protectedGlobs config field. It was resolved, merged, persisted, and read by nothing. The lesson: a config field with no reader isn't a policy, it's a comment that costs a migration.

The enforcement point ended up in the squash, not in setup. "Arbitrary shell must never touch tracked files" is a rule I can't enforce. "This squash contains no protected path" is a rule I can check at exactly the right moment:

git add -A
git reset --soft "$BASE_SHA"
# staged paths matching a protected glob, from `git diff --cached --name-only -z`:
git reset -q "$BASE_SHA" -- "${excluded[@]}"

That last reset puts each protected path's index entry back to how it was at base. A protected file the agent created didn't exist at base, so it drops out of the index entirely.

VADD then emits an event naming every path it excluded. A squash that silently leaves out a file the agent believed it changed is the same kind of lie as a dropped log line.

One more ordering bug turned up here. The first version refused to integrate when it couldn't read the policy, but it made that check after reset --soft had already moved the branch. A refusal that happens after the first mutating step isn't a refusal. Read everything a guard needs before you touch the worktree.

6. Two worktrees, one ID

The last one isn't really git's fault. My plan-task table used the task's ordinal ('0', '1', '2') as a global primary key. That's unique within one objective and not unique anywhere else. The second objective to reach planning hit a UNIQUE violation, the error was swallowed, and the user was shown a plan with no rows behind it.

Every test used one objective at a time. A fixture with one of the thing under test can't show you a collision between two of them. If you're isolating parallel work, make sure your tests run parallel work.

The checklist

If you're building on worktrees for agents:

After removal, assert both that git no longer lists the path and that it's gone from disk.
Scan the worktree root yourself. git worktree list can't see a directory git has already forgotten.
Run dependency setup at worktree creation, and treat a setup failure as a hard stop.
Don't trust cp -al with files owned by another user.
Check whether anything in the project is bind-mounted to the main checkout.
Enforce "don't commit this" where the commit happens, and report what you excluded.
Test with two or more concurrent worktrees.

All of this is in VADD's repo under packages/server/src/git/, and the full list of traps is in CLAUDE.md. Next post: the process-management side of running an agent's test suite, where a 1-second timeout took 5 seconds and left the process running.

About 1,800 tests passed. Running the real app found 14 bugs

Serhii — Tue, 22 Sep 2026 15:35:47 +0000

My last post about Filament Studio was about v1.2.0 and multilingual content, back in April.

Since then I have shipped two larger things: an MCP server, so AI agents can manage collections and records, and Flows, an automation engine inside the plugin. Flows has a visual designer, four trigger types (manual, webhook, collection event, cron), a set of operations (create/update records, HTTP requests, email, conditions, calling another flow), draft/publish versioning, and a step-through debugger.

By the end of August the test suite was at about 1,800 tests. I run mutation testing on top of that, with an 80% MSI target per module. By the numbers I had, Flows was in good shape.

In September I stopped trusting those numbers and did something I should have done earlier. I installed the package into a separate Laravel app and used it the way a user would:

real HTTPS webhook deliveries
a real queue worker
MySQL instead of in-memory SQLite
the admin panel, clicked through in a browser

That found fourteen defects in one release (v1.8.0), plus one more the day before (v1.7.1). The existing suite covered none of them.

This post goes through the interesting ones. What I took from it: almost every bug had the same shape. The system reported success while doing nothing, or doing the wrong thing.

1. A run that completed in 0 ms

The first bug showed up before I had even started on webhooks.

I opened a seeded "Welcome Email" flow, triggered it, and the run page said Completed. Duration: 0 ms. Steps: none.

Nothing had run, and the engine said everything was fine.

The engine walks the flow as a graph. After each node it asks for the successors on the success branch (or failure). The lookup matched the edge's sourceHandle exactly:

// Before
$matches = $matches->where('sourceHandle', $branch);

The visual designer always sets sourceHandle, because its nodes have named success and failure handles. But a graph written by hand, by a seeder, or through the REST API usually looks like this:

{ "source": "trigger", "target": "send_email" }

No handle. So the walk stopped at the trigger, found nothing to do, and finished. "Finished with nothing to do" was recorded as success.

// After
$matches = $matches->filter(
    fn (array $edge): bool => ($edge['sourceHandle'] ?? 'success') === $branch,
);

Every graph in my tests had the shape the designer produces. The engine had only ever been tested on input from its own UI.

2. A webhook that looked signed but accepted anyone

This is the one I am least proud of.

Flows can be triggered by a webhook, and the default auth mode is HMAC: the sender signs "{timestamp}.{body}" with a shared secret, and the endpoint checks the signature.

A few things combined here:

The flow table has a webhook_auth_mode column that defaults to hmac.
The secret was generated only when the trigger node's config contained auth_mode: hmac.
The trigger's config schema never declared an auth_mode field, so the designer never showed it and nobody could set it.
So on the normal path, webhook_secret stayed NULL.
The verifier took the secret as a string. (string) null is ''.

The endpoint said it required a signature, but anyone who could compute hash_hmac('sha256', "{ts}.{body}", '') could pass the check. That is anyone.

The fix has two parts. First, the verifier refuses to verify against an empty secret:

if ($secret === '') {
    // Without this guard an unconfigured flow verifies against hash_hmac(..., ''),
    // which any caller can compute — an unauthenticated endpoint that looks signed.
    throw new InvalidWebhookSignatureException('Webhook secret is not configured for this flow.');
}

Second, the trigger now reads the webhook_auth_mode column instead of node config. The webhook trigger node has no config at all anymore. Auth mode, secret, API-key allowlist and redaction paths all live on the flow record, so there is one source of truth.

The real bug was having two places to set one security setting. Each had its own tests, and nothing checked that they agreed.

If you run Flows with a reachable webhook: check for flows where webhook_auth_mode = 'hmac' and webhook_secret IS NULL. Those endpoints were effectively public. After upgrading, publish the flow again and a secret will be generated. Until then it returns 401.

In the same area, webhook_redact_paths redacted the parsed body but not the raw body stored next to it, so a value scrubbed from body still sat in trigger_payload.raw. The raw body is now re-encoded from the sanitized one.

3. `Cache::forever` is not forever

Collection-event triggers ("run this flow when a record in orders is created") need a fast lookup: given a collection and an event, which flows care?

I kept that index in the cache:

Cache::forever('studio.flows.collection_event_subscriptions', $subscriptions);

When a flow was published, it subscribed. When unpublished, it unsubscribed. The tests passed.

Then I ran php artisan optimize:clear, which plenty of deploy scripts run. Every collection-event flow stopped firing. Nothing was logged and nothing showed in the UI. The only way to recover was to publish every flow again.

"Forever" in a cache means "until something clears it": a deploy, an eviction, a Redis restart. The cache was the only record of the subscriptions, so losing it lost the data.

The fix makes the cache a read-through index over what is actually published:

public function all(): array
{
    $cached = Cache::get(self::CACHE_KEY);

    // An explicitly empty map is a real answer — every flow unsubscribed.
    // Only a missing key means the index was lost and must be rebuilt.
    if ($cached !== null) {
        return $cached;
    }

    $rebuilt = $this->rebuildFromPublishedVersions();
    Cache::forever(self::CACHE_KEY, $rebuilt);

    return $rebuilt;
}

The comment covers a detail I almost got wrong: [] (nobody subscribed) and null (the index is gone) have to be treated differently. Otherwise an install with no subscriptions would query the database on every record save.

Since then, whenever I put something in the cache, I ask: if this key disappears right now, what breaks, and would anyone notice?

4. Config schemas that disagreed with the code reading them

Each trigger declares a config schema. The designer renders a form from it and the API validates against it. Separately, the trigger's runtime code reads config keys.

In three of the four triggers, these didn't match:

Trigger	Schema declared	Runtime read	Result
Collection event	`collection_id`, `event`	`collection`, `events`	Flow never subscribed
Schedule	`cron_expression`	`cron`	Flow failed to publish: `Invalid cron expression:`
Webhook	`secret_key`, `expected_method`	nothing	Fields that did nothing

A schedule flow configured exactly as its own schema described could not be published.

There were tests for the schemas and tests for the runtime. None of them built a config from the schema and gave it to the runtime.

5. Secrets that were never injected

Flows support per-flow encrypted secrets, used in configs as {{ $secrets.API_TOKEN }}.

The table existed. Encryption at rest worked. FlowContext had a $secrets slot, and the template engine knew how to resolve $secrets.*.

Nothing ever filled the slot. Every {{ $secrets.X }} rendered as an empty string, so any flow using one was sending an empty credential.

Wiring it up was the easy part. The harder part was what the secrets must not leak into:

Step logs. Values are already masked by key name (/token/i, /password/i, …), but a secret interpolated into a URL or into a field called note gets past key-name matching. Resolved secret values are now scrubbed from every string before a step is saved.
The step-through cache. A paused debugging session stores its context in the cache store. Secrets are left out of that blob and loaded from the database again when the session resumes.
Sub-flows. A flow that triggers another flow doesn't pass its secrets along. The child loads its own.

6. The quick ones

Each of these deserves a paragraph, but the pattern is clear by now:

Form-encoded webhooks wrote blank records, and the run showed as successful. The body was parsed only when $request->isJson(), so {{ $trigger.body.email }} rendered as ''.
The run timeline listed steps alphabetically. Sorting used started_at, which has second precision. In a fast run every step ties, and MySQL fell back to index order, which was alphabetical by operation key. It now tie-breaks on the UUIDv7 primary key, which increases monotonically.
Every fast step showed 0ms for the same reason. There is now a duration_ms column measured by the engine.
A synchronous "trigger another flow" step reported success when the child flow failed. It now takes the failure branch.
The Studio Dashboard page returned 403 for everyone using spatie/laravel-permission. It checked a permission name that the package never registers.
The audit log recorded updated for every lifecycle change: draft save, publish, rollback. Now they are draft_saved, published, rolled_back.
Which API answered depended on service-provider boot order. Collection routes are a catch-all, api/studio/{collection_slug}, so GET /api/studio/flows went to the collection controller when it was registered first.

The route fix gave me a small lesson of its own. My first version excluded reserved segments with a lookahead ending in $:

'(?!(?:flows|webhooks)$)[^/]+'

The regression test failed. Laravel splices the parameter pattern into the regex for the whole path, so $ doesn't mean the end of the segment. /api/studio/webhooks/my-flow still matched. The working version ends the lookahead at a segment boundary:

'(?!(?:flows|webhooks)(?:/|$))[^/]+'

I only caught that because I wrote the test first. That was the rule for this release: every one of the fourteen fixes started with a test that failed.

Two older bugs from the same family

Looking back, I had seen this pattern before and hadn't named it.

Search that returned nothing. In v1.5.0 I fixed record search, which matched nothing for any term. Filament's default searchable() generated where "column" like ? against the records table. But in an EAV model, the values live in another table, and on the record query they exist only as subquery aliases, which a WHERE clause can't reference. On MySQL that throws Unknown column. On SQLite, which my tests used, an unresolved double-quoted identifier quietly turns into a string literal. So the query compared the literal string 'title' to the search term and returned zero rows, and the tests passed.

A dependency I never used. The v1.4.0 changelog said Flows was "built on durable-workflow/workflow". It wasn't. Nothing in the package referenced it. The engine had always walked its own graph and used plain Laravel queued jobs. I removed it in v1.7.0 (three fewer packages and about thirty fewer migrations on every install) and corrected the changelog. It wasn't a runtime bug, but it was the same problem in documentation: a claim nobody had checked against reality.

The pattern

Grouped together, the fifteen or so bugs fall into three categories.

1. Silent success. The system's default outcome was "success", so doing nothing looked the same as doing the job. A 0 ms run, a blank record, a swallowed child failure, an empty credential, a subscription index that disappeared, a search with no results. None of them threw an exception.

2. Two things that should agree, tested separately. Schema vs. runtime. Flow column vs. node config. Designer-shaped graphs vs. API-shaped graphs. Collection routes vs. flow routes. A policy's permission name vs. the permissions that exist. Each side had tests, and the gap between them had none.

3. A test environment gentler than production. SQLite that forgives bad SQL. A cache that never gets flushed mid-test. Requests that are always JSON.

A green suite showed that the code did what the tests said. It said much less about whether the product worked.

What I changed

An end-to-end pass in a real host app before releases: real queue, real database engine, real HTTP. It's slow and manual, and it found more in a week than the suite had in months.
A failing test first for every bug, so each bug from this list is now permanently covered.
Checking where "success" comes from. For each code path that reports success, I ask what it reports when nothing happened.
Asking what happens if the cache key disappears, every time I write one.

v1.8.0 is out with all of this. Upgrading is php artisan migrate (for duration_ms). There are two behavior changes: a collection with the slug flows or webhooks is no longer reachable through the collection API, and HMAC webhooks without a secret now return 401. The changelog has the details.

What I would like to hear

Do you run an end-to-end pass against a real host app for your Laravel packages? How much of it is automated?
Has Cache::forever bitten you, or have you been using the cache as an index from the start?
For "silent success": do you have a pattern for making "nothing happened" look different from "it worked"?

Repo: https://github.com/serhii-f8/filament-studio
Packagist: https://packagist.org/packages/serhii-f8/filament-studio

If you have a good way to catch "two things that should agree" bugs before a user does, I would like to hear it.

I shipped Filament Studio 1.3.0, and it is the first version that feels AI-ready

Serhii — Sun, 10 May 2026 16:20:20 +0000

I have been building Filament Studio as a dynamic data model manager for Filament v5 and Laravel 12.

The original value prop was runtime-defined collections and fields on top of an EAV model, so you can build flexible admin/data systems without creating a new migration for every content type.

That part worked.

But while working on the project, I kept coming back to a different question:

If this data layer is dynamic, how should an AI agent interact with it?

My answer in v1.3.0 was to add the MCP foundation instead of hacking together one-off AI endpoints.

So this release makes Filament Studio usable as an AI-facing layer, not just an admin-facing one.

What I added in `v1.3.0`

MCP server foundation under src/Mcp/
HTTP/SSE transport mounted at /ai/studio
stdio transport via php artisan mcp:start studio
Reuse of StudioApiKey for MCP auth
New management scope namespace for MCP operations
Capability discovery resources like:
- studio://info
- studio://field-types
- studio://panel-types
- studio://operators
12 schema-management MCP tools for collections and fields
Confirm-token flow for destructive operations
Canonical serializer + exception handling for tool responses
Tenant-aware behavior aligned with the rest of Studio

Why I think this matters

A lot of AI integration work feels shallow to me.

Either there is a chat UI bolted on top, or there is an agent wired straight into places it probably should not be touching.

For a system like Filament Studio, neither approach feels right.

If the schema is dynamic, the agent needs a real contract:

discover what exists
inspect schema safely
mutate collections and fields through structured tools
handle destructive actions with explicit confirmation tokens
work through auth scopes instead of bypassing application boundaries

That is the part I wanted to build first.

What changed for me conceptually

Before this release, Filament Studio was mainly a human-operated system.

After this release, it is starting to become an agent-addressable one.

That is a much more interesting direction than sprinkling AI on top of the UI.

I want the data model, schema rules, and operational boundaries of a Laravel app to be available to agents in a structured way.

v1.3.0 is my first serious pass at that.

What this release is not

This is not the final AI story for the project.

It is the foundation.

I started with schema management because if that layer is weak, everything above it becomes fragile.

So I would rather get the contract right first, then expand the workflows on top of it.

If you are building with Filament and thinking about AI agents beyond demo-level features, this is the direction I am building toward.

Follow the project if you want to see where the MCP roadmap goes next.

Feedback I would like
Filament Studio v1.3.0 is available now.

GitHub: https://github.com/flexpik/filament-studio
Packagist: https://packagist.org/packages/flexpik/filament-studio

Building multilingual runtime collections in a Filament plugin

Serhii — Wed, 15 Apr 2026 20:46:01 +0000

Building multilingual runtime collections in a Filament plugin

I just released v1.2.0 of Filament Studio, a Filament v5 plugin I am building for runtime collections, custom fields, dashboards, filters, and APIs.

The short version: this release adds multilingual support.

The longer version: adding multilingual support to a runtime data model is not the same as adding a translations JSON column and moving on.

Filament Studio is built for admin panels where the data model changes after the app is already running. A user can create a collection, add fields, manage records, build dashboards, and expose API endpoints without writing a new migration and Filament resource for each new content type.

That flexibility creates a specific problem for translations.

If the fields are defined at runtime, translation behavior also has to be defined at runtime.

The problem I wanted to solve

In real admin systems, multilingual content is rarely all-or-nothing.

A collection might support English and French.

Inside that collection:

title should be translated
description should be translated
price should stay shared
published_at should stay shared
is_featured should stay shared

That means translation behavior belongs at the field level, not only at the record or collection level.

I also wanted the feature to work across the whole plugin:

generated Filament forms
EAV storage
query builder reads and writes
REST API responses
OpenAPI documentation
fallback behavior
version snapshots

Otherwise it would feel like a partial feature.

Global and collection config

Multilingual support is opt-in.

// config/filament-studio.php
'locales' => [
    'enabled' => true,
    'available' => ['en', 'fr', 'de'],
    'default' => 'en',
],

You can also enable it through the environment:

STUDIO_LOCALES_ENABLED=true

Each collection can then define its own supported locales and default locale:

$collection->update([
    'supported_locales' => ['en', 'fr'],
    'default_locale' => 'en',
]);

If a collection does not define supported locales, it uses the global list.

Per-field translation

Each field now has a translatable flag.

That lets a collection mix localized and shared data:

title        translatable
description  translatable
price        shared
published_at shared
is_featured  shared

This is the part of the design I care about most. In multilingual admin work, not every value is content. Some values are facts, flags, prices, dates, or relationships. Treating all of them as translatable creates noise and sometimes bugs.

Storage model

Filament Studio uses an EAV model because fields are created at runtime.

For v1.2.0, the studio_values table now includes a locale column.

For translatable fields, values are stored per locale.

For shared fields, one value is used regardless of active locale.

The uniqueness boundary is:

record_id + field_id + locale

That allows a record to have different localized values for the same runtime field without creating new database columns for every translated field.

Locale resolution

I added a dedicated LocaleResolver service so the rules live in one place.

The active locale is resolved in this order:

?locale= query parameter
X-Locale header
session
collection default
global default

That gives API consumers a direct way to request a locale, while the admin panel can remember the selected locale in the session.

Query builder API

The EavQueryBuilder now supports a locale() method:

$data = EavQueryBuilder::for($collection)
    ->locale('fr')
    ->getRecordData($record);

Create and update operations can also target a locale:

$record = EavQueryBuilder::for($collection)
    ->locale('fr')
    ->create([
        'title' => 'Mon Titre',
    ]);

EavQueryBuilder::for($collection)
    ->locale('fr')
    ->update($record->id, [
        'title' => 'Titre mis a jour',
    ]);

There is also getAllLocaleData() for retrieving every translation at once:

$allData = EavQueryBuilder::for($collection)
    ->getAllLocaleData($record);

Example result:

[
    'title' => [
        'en' => 'My Title',
        'fr' => 'Mon Titre',
    ],
    'price' => 29.99,
]

Translatable fields return locale maps. Shared fields stay plain.

Fallback metadata

I did not want fallback behavior to be silent.

If an API client asks for French and a field falls back to English, the client should be able to detect that.

So getRecordDataWithMeta() returns fallback information:

$result = EavQueryBuilder::for($collection)
    ->locale('fr')
    ->getRecordDataWithMeta($record);

Example:

[
    'data' => [
        'title' => 'Mon Titre',
        'slug' => 'my-slug',
    ],
    'fallbacks' => ['slug'],
]

That tells the caller that slug came from the default locale.

REST API support

API endpoints now accept locale selection through query params:

curl -H "X-Api-Key: your-key" \
     "https://your-app.com/api/studio/posts?locale=fr"

or through headers:

curl -H "X-Api-Key: your-key" \
     -H "X-Locale: fr" \
     "https://your-app.com/api/studio/posts"

Responses include metadata:

{
  "data": {
    "uuid": "550e8400-e29b-41d4-a716-446655440000",
    "data": {
      "title": "Mon Titre",
      "slug": "my-slug",
      "price": 29.99
    }
  },
  "_meta": {
    "locale": "fr",
    "fallbacks": ["slug"]
  }
}

For single-record reads, all_locales=true returns every locale:

curl -H "X-Api-Key: your-key" \
     "https://your-app.com/api/studio/posts/550e8400?all_locales=true"

OpenAPI docs

When multilingual support is enabled, the generated OpenAPI docs include:

locale query parameter
X-Locale header parameter
all_locales query parameter
_meta.locale
_meta.fallbacks

This felt worth doing because API features are easy to misunderstand when the docs do not show the request and response shape.

Admin UI and versioning

In the Filament admin, multilingual collections now get a locale switcher on record pages.

Editors can switch locale and edit only the fields that should change for that locale.

Version snapshots also store all locale values for translatable fields:

{
  "title": {
    "en": "My Title",
    "fr": "Mon Titre"
  },
  "slug": {
    "en": "my-slug"
  },
  "price": 29.99
}

That way restoring a version does not only restore whichever locale happened to be active at the time.

Why I am sharing this

This was one of those updates that made the package feel more practical.

The first version of a dynamic admin builder can look good with just runtime fields and generated forms.

But real projects keep asking for the less glamorous pieces:

permissions
APIs
versioning
tenancy
filtering
multilingual content

That is the direction I am trying to push Filament Studio.

GitHub: https://github.com/flexpik/filament-studio

Packagist: https://packagist.org/packages/flexpik/filament-studio

If you have built multilingual admin panels in Laravel, I would like feedback on the model:

should translation behavior live per field?
is fallback metadata useful in practice?
would all_locales=true work for your API use cases?
what edge cases am I missing?

I built a Filament plugin for runtime collections, custom fields, dashboards, and APIs

Serhii — Mon, 06 Apr 2026 10:54:30 +0000

I built a Filament plugin for runtime collections, custom fields, dashboards, and APIs

I built Filament Studio because I got tired of the same cycle in Laravel projects.

The admin panel starts simple.

Then requirements change.

A client wants a new content type.

Then custom fields.

Then better filtering.

Then dashboards.

Then API access.

Then tenant-specific data.

Then version history.

Then another special case nobody planned for.

At that point, what looked like a straightforward Filament setup turns into more migrations, more models, more resources, more filters, and more maintenance.

That gets old fast.

So I built a plugin for Filament v5 that lets you create and manage data collections at runtime, define fields through the UI, manage records, build dashboards, and expose API endpoints without creating a new table and Filament resource every time the model changes.

The plugin is called Filament Studio.

The problem I wanted to solve

Filament is excellent when the data model is already clear and relatively stable.

But some projects are not like that at all.

You might be building:

a flexible internal CMS
a client-specific admin panel
an operations dashboard
a multi-tenant back office
a content platform where structure changes over time

In those projects, the data model is usually the part that keeps moving.

And every change has a cost.

A new content type is not just "add a few fields."

It usually means:

another migration
another model
another Filament resource
another set of forms and table columns
another round of filters and policies
another layer of maintenance

I wanted a way to stay inside Filament while making the admin side much more flexible.

What Filament Studio does

Filament Studio turns Filament into a runtime-configurable data platform.

With it, you can:

create collections from the admin UI
define custom fields without writing migrations for each collection
manage records with generated forms, tables, and filters
build dashboards with metrics and chart panels
expose REST API endpoints with API key authentication
enable versioning and soft deletes
scope everything by tenant
control access with policies and permissions
extend the system with custom field types, panel types, hooks, and schema modifiers

I was not trying to build a toy form builder.

I wanted something that still feels useful when the project becomes real.

Why I chose an EAV-based approach

The core of Filament Studio is an EAV storage model.

Instead of creating a new database table for every collection, the plugin stores:

collection definitions
field definitions
records
typed values

That gives the plugin room to support runtime schema changes without forcing a migration every time someone adds or edits a field.

I know EAV has a reputation.

Sometimes that reputation is deserved.

But in this case, the tradeoff made sense because I was not trying to model one stable domain perfectly.

I was trying to give teams a flexible way to build evolving admin-managed data systems inside Filament.

The important part was making it practical:

typed storage columns
generated Filament components
useful filtering
dashboards
API support
extensibility hooks
production-oriented features like tenancy and authorization

What's built in

Filament Studio already includes a lot of what I usually end up rebuilding by hand.

Dynamic collections

You can create collections in the admin panel and define fields visually.

The plugin currently includes 33 built-in field types across categories like:

text
numeric
boolean
selection
date and time
file
relational
structured
presentation

That makes it useful for more than simple text-entry forms.

Dashboard builder

There is also a dashboard builder with 9 panel types, including metrics, lists, time-series charts, bar charts, pie charts, and more.

That matters because once teams have data, the next thing they ask for is visibility.

Advanced filtering

I also wanted filtering to be good enough for real admin use, not just "search one text column."

So the plugin includes:

a visual filter builder
nested AND/OR logic
dynamic variables
saved presets
type-aware operators

REST API

Filament Studio can generate REST API endpoints with:

API key authentication
per-collection permissions
rate limiting
OpenAPI documentation

Production-oriented features

A lot of packages stop at the demo layer.

I wanted this one to go further, so it also supports:

multi-tenancy
authorization
record versioning
soft deletes
lifecycle hooks
schema modification callbacks
custom field and panel extensions

Who I think this is useful for

I think Filament Studio is most useful for three groups.

Laravel and Filament developers

If you like building with Filament but do not want every new admin requirement to trigger another round of scaffolding, this gives you a more flexible starting point.

Agencies

If you build custom admin panels for clients, this can reduce the amount of repetitive work involved in creating content structures, dashboards, and internal workflows.

Startup teams

If your internal systems and content models are still evolving, runtime collections can be easier to live with than constantly reshaping your app around new admin requirements.

What I wanted the plugin to feel like

I did not want this to feel like a disconnected "builder product" bolted onto Laravel.

I wanted it to still feel like it belongs in a Filament application.

That meant:

native-looking forms and tables
sensible extension points
support for real authorization models
room for custom field types and custom panels
documentation good enough that people can actually adopt it

I also spent time on screenshots and docs because I think open-source packages need to earn trust quickly.

If someone lands on the repository, they should immediately understand what the plugin does, what it looks like, and whether it is serious.

Why I'm sharing it now

I am sharing Filament Studio because I think it fills a real gap in a certain kind of Laravel project.

Not every app needs runtime-defined collections.

But when a project does need flexibility, the usual alternatives are messy:

keep hardcoding every change
overbuild a custom internal CMS
stitch together several tools
give up on having a clean workflow inside Filament

I wanted a better option.

If this sounds useful, I'd love feedback

If you work with Laravel and Filament and this solves a problem you've run into, take a look:

GitHub: https://github.com/flexpik/filament-studio
Packagist: https://packagist.org/packages/flexpik/filament-studio

If it looks useful:

star the repo
try it in a project
tell me what you'd build with it
tell me what feels missing

The most useful feedback at this stage is not just "looks nice."

It is "this would help me build X" or "I would need Y before using it."

That kind of feedback is what makes open-source tools better.

10 Reasons Why PrestaShop Is the Best E-commerce Platform for Your Business

Serhii — Tue, 21 Mar 2023 10:01:02 +0000

Introduction

Are you looking to start or expand your e-commerce business? With so many platforms available, it can be challenging to determine which one is the best fit for your specific needs. In this article, we will delve into 10 reasons why PrestaShop is the best e-commerce platform for your business, and why it should be at the top of your list.

1. User-friendly Interface

Intuitive dashboard
PrestaShop boasts a user-friendly interface with an intuitive dashboard that even beginners can easily navigate. The admin panel is designed with simplicity in mind, making it easy to manage your online store with minimal effort.

Easy customization
With PrestaShop, customizing your online store is a breeze. You can easily modify the look and feel of your site, add new features, and make changes to your store's layout without any coding knowledge.

2. Wide Range of Features

Built-in SEO tools
PrestaShop comes with a set of built-in SEO tools that help you optimize your online store for search engines. These tools include customizable meta titles, descriptions, and URLs, making it easy to improve your store's search engine rankings.

Powerful analytics
The platform offers robust analytics features that allow you to track your store's performance and make data-driven decisions. You can monitor sales, visitor behavior, and other key metrics with ease, helping you optimize your business strategy and grow your revenue.

3. Extensive Theme Selection

PrestaShop offers a vast selection of professionally designed themes, ensuring that your online store looks attractive and engaging. You can choose from a wide variety of free and premium themes, making it easy to find one that matches your brand identity and appeals to your target audience.

4. Scalability

PrestaShop is a highly scalable e-commerce platform, making it an ideal choice for businesses of all sizes. As your business grows, you can easily add new features, products, and categories without experiencing any significant slowdowns or performance issues.

5. Multilingual and Multi-currency Support

Operating an international e-commerce business? PrestaShop has you covered with its multilingual and multi-currency support. The platform allows you to offer your products in multiple languages and accept payments in various currencies, making it easier for you to cater to a global audience.

6. Large Community and Support Network

Active forums
PrestaShop has a large and active community of users, developers, and experts who are always ready to help. The platform's forums are filled with knowledgeable individuals who can offer advice, tips,and troubleshooting assistance whenever you need it.

Documentation and tutorials
PrestaShop also provides extensive documentation and tutorials, ensuring that you have all the resources you need to manage your online store effectively. These resources cover a wide range of topics, from basic setup to advanced customization and optimization techniques.

7. Cost-effective Solution

PrestaShop is an open-source platform, which means it's free to download and use. This makes it an attractive option for small businesses and startups on a tight budget. While there are some premium features and themes available for purchase, the core functionality of the platform is available at no cost.

8. High-level Security

Security is a top priority for any e-commerce business. PrestaShop takes this concern seriously by providing a secure platform that is regularly updated to address potential vulnerabilities. The platform also offers features like SSL support and PCI compliance, ensuring that your customers' sensitive data is protected.

9. Seamless Third-party Integrations

PrestaShop is highly compatible with various third-party services and applications, making it easy to integrate your online store with other tools and platforms. From payment gateways to shipping providers and marketing tools, PrestaShop's extensive ecosystem allows you to build a comprehensive e-commerce solution tailored to your specific needs.

10. Mobile-friendliness

With the ever-increasing importance of mobile commerce, having a mobile-friendly online store is essential. PrestaShop's responsive design ensures that your website looks great and functions smoothly on all devices, providing a seamless shopping experience for your customers.

Conclusion

In conclusion, PrestaShop is an excellent e-commerce platform that offers a wide range of features, scalability, and a user-friendly interface, making it an ideal choice for businesses of all sizes. By choosing PrestaShop, you can build a powerful online store that is easy to manage, secure, and ready to scale as your business grows.

FAQs

Q1: Can I migrate my existing online store to PrestaShop?

Yes, PrestaShop offers tools and resources to help you migrate your existing online store from another platform to PrestaShop. You can also seek assistance from the community or hire a professional to handle the migration process.

Q2: Does PrestaShop offer hosting services?

PrestaShop does not provide hosting services directly. However, the platform is compatible with various hosting providers, allowing you to choose the best hosting solution for your specific needs.

Q3: How customizable is PrestaShop?

PrestaShop is highly customizable, allowing you to tailor the appearance and functionality of your online store to suit your preferences. With a wide range of themes and modules available, you can create a unique shopping experience for your customers.

Q4: Is PrestaShop suitable for large-scale e-commerce businesses?

Yes, PrestaShop is designed to accommodate businesses of all sizes, including large-scale enterprises. Its scalability and extensive feature set make it an excellent choice for businesses with a large product catalog and high sales volume.

Q5: Can I use my own domain name with PrestaShop?

Yes, you can use your own domain name with PrestaShop. The platform allows you to connect your custom domain to your online store, ensuring that your branding remains consistent across all channels.

DEV Community: Serhii

Git worktrees as agent isolation: what broke, with the code

1. git worktree remove can succeed while the files stay on disk

2. A fresh worktree can't run the project's tests

3. Hard-linking dependencies silently skips files

4. docker compose exec works on the wrong checkout

5. Protected files leaked into the squash commit

6. Two worktrees, one ID

The checklist

About 1,800 tests passed. Running the real app found 14 bugs

1. A run that completed in 0 ms

2. A webhook that looked signed but accepted anyone

3. Cache::forever is not forever

4. Config schemas that disagreed with the code reading them

5. Secrets that were never injected

6. The quick ones

Two older bugs from the same family

The pattern

What I changed

What I would like to hear

I shipped Filament Studio 1.3.0, and it is the first version that feels AI-ready

What I added in v1.3.0

Why I think this matters

What changed for me conceptually

What this release is not

Building multilingual runtime collections in a Filament plugin

Building multilingual runtime collections in a Filament plugin

The problem I wanted to solve

Global and collection config

Per-field translation

Storage model

Locale resolution

Query builder API

Fallback metadata

REST API support

OpenAPI docs

Admin UI and versioning

Why I am sharing this

I built a Filament plugin for runtime collections, custom fields, dashboards, and APIs

I built a Filament plugin for runtime collections, custom fields, dashboards, and APIs

The problem I wanted to solve

What Filament Studio does

Why I chose an EAV-based approach

What's built in

Dynamic collections

Dashboard builder

Advanced filtering

REST API

Production-oriented features

Who I think this is useful for

Laravel and Filament developers

Agencies

Startup teams

What I wanted the plugin to feel like

Why I'm sharing it now

If this sounds useful, I'd love feedback

10 Reasons Why PrestaShop Is the Best E-commerce Platform for Your Business

Introduction

1. User-friendly Interface

2. Wide Range of Features

3. Extensive Theme Selection

4. Scalability

5. Multilingual and Multi-currency Support

6. Large Community and Support Network

7. Cost-effective Solution

8. High-level Security

9. Seamless Third-party Integrations

10. Mobile-friendliness

Conclusion

FAQs

1. `git worktree remove` can succeed while the files stay on disk

4. `docker compose exec` works on the wrong checkout

3. `Cache::forever` is not forever

What I added in `v1.3.0`