Problem

In a typical Kubernetes deployment (e.g., Falco Helm chart), falcoctl is often used in two phases:

1. An init container runs falcoctl artifact install to populate a shared volume with plugins/rules.
2. A sidecar container runs falcoctl artifact follow to keep them updated.

Currently, when the sidecar starts, it has no knowledge of what the init container has just installed. It treats the local state as "empty" or "unknown" and immediately queries the OCI registry (e.g., GHCR) to resolve tags and fetch manifests. This causes:

• Redundant network requests (Rate Limiting risks on GHCR).
• Unnecessary re-verification of artifacts that are already present.

Proposed Solution

Implement a "Write and Read" state mechanism to share context between commands via the filesystem.

1. Write State (artifact install)
Modify the install command to persist the digest of the installed artifact to a state file in the destination directory (e.g., alongside the plugin/rules files).

• Where: install.go
• Action: After a successful extraction, call artifactstate.Write(destDir, ref, digest).

2. Read State (artifact follow)
Modify the follow command to check for this state file during initialization.

• Where: follower.go
• Action: In the New constructor, attempt to read the persisted digest using artifactstate.Read.
• Logic: If a state is found, initialize the follower's currentDigest with it. This allows the follower to know immediately that the artifact is already at version X, potentially skipping the initial update check or download.

Benefits

• Traffic Reduction: Drastically reduces the number of requests to OCI registries during Pod startup/restart.
• Optimization: The sidecar becomes "aware" of the work done by the init container.