Concepts

References

References

Files GPAL Writes to Disk

GPAL.yaml - Created and Loaded Automatically

The first time your workflow runs in a given directory, GPAL.yaml does not exist, so GPAL creates it next to your executable with default settings and publishes a warning event. On every run after that, GPAL loads it automatically and confirms with an info event. GPAL.yaml holds the same settings you can configure in code -- match thresholds, typing delays, driver behavior. Call GPAL.SaveSettings() to persist runtime changes back to disk. Both LoadSettings() and SaveSettings() accept an optional GPALFile: pass one to redirect to a different path, and that path becomes the session default for all subsequent no-arg calls.

GPAL.WithInformationHandler(InformationEventHandler);


// First run: GPAL.yaml does not exist, creates it with defaults (WARNING).

// Every later run: loads GPAL.yaml automatically (INFO).

GPAL.WithImageMatchingPercentage(90);


// the download timeout belongs to a browser, so it is set where the browser is built

GPAL.Browser

.WithBrowserType(BrowserType.Chrome)

.WithDownloadTimeoutInSec(30);

GPAL.SaveSettings();


// Load from a shared location

// All subsequent no-arg SaveSettings() calls use this path automatically.

GPAL.LoadSettings("C:/shared/GPAL.yaml");

NOTE

Call GPAL.LoadSettings() with a GPALFile early in your workflow to point GPAL.yaml at a shared or environment-specific location. That path becomes the session default -- subsequent no-arg LoadSettings() and SaveSettings() calls use it automatically for the rest of the run.

Optional Config Files - Load, Save, and Custom Paths

Beyond GPAL.yaml, a small set of optional config files can be written to disk when you want to tune behavior without recompiling. All four classes follow the same pattern: Load() and Save() accept an optional GPALFile. With no argument, each uses its own default path next to your executable. Pass a GPALFile to redirect to a different path -- that path becomes the new in-session default.

// the mail object first, then the server settings and the envelope on it

IGPALMail mail = GPAL.Mail.ToGPALObject();


// No-arg: each class uses its own default path

CredentialsConfig creds = CredentialsConfig.Load(); // ./credentialsConfig.json

CredentialsConfig.Save();


// Pass a GPALFile to redirect

creds = CredentialsConfig.Load(

"config/creds.json");

creds.GoogleRestRedirectUri = "http://localhost:3000/access-token";

CredentialsConfig.Save(); // config/creds.json

CredentialsConfig.Save(); // still config/creds.json


// Same pattern for DigestRulesConfig and AIProvidersConfig

DigestRulesConfig.Save((GPALFile)"config/rules.yaml");

DigestRulesConfig.Save(); // config/rules.yaml


// GPALMail uses ./GPALMail.yaml by default

mail.LoadSettings();

mail.LoadSettings("config/mail.yaml");

mail.SaveSettings(); // config/mail.yaml


// AIProvidersConfig

AIProvidersConfig providers = AIProvidersConfig.Load(); // ./AIProvidersConfig.yaml

providers.Save((GPALFile)"config/ai-providers.yaml");

NOTE

Passing a GPALFile becomes the new session default for all subsequent no-arg calls, and Load never writes to disk. LLMDigestRules.yaml is the one that rewrites itself: an older single section file is migrated to the two section format, and the original is copied to LLMDigestRules.yaml.v0.bak first. A second migration numbers itself .v0.1.bak rather than writing over the first, so nothing is lost.

Written As A Side Effect Of The Work

Nothing below is a setting you turn on. Each one is written because a workflow asked for something that needs it. GPAL.Logger writes log files wherever WithRootDirectory points, in the folder shape WithDirectoryStructure chooses, and it only exists once a workflow builds one: no logger, no log files. A driver GPAL downloads for you lands in the driver location, the archive and the binary both. A workflow that names no profile gets a throwaway one built under the temp directory and removed when the browser closes, and a workflow that names a real profile has that profile written to: Chrome preferences, or user.js on Firefox, put back once the browser process has gone. A hidden desktop writes GPALReturnToDefaultDesktop.ps1 beside the binary, because a desktop nobody can see needs a way back that does not depend on the workflow still running. GPALRestAPI keeps ports-in-use.log beside its own exe, a line of pid and port per running host, so several browsers at once can be told apart. It is written for reading, not by GPAL: a host takes whichever port the operating system gives it and never consults the file.

// a logger is the only reason GPAL writes a log

GPAL.Logger

.WithRootDirectory(@"C:Logs")

.WithDirectoryStructure(DirectoryStructure.YMD)

.WithFilename("run.log")

.ToGPALObject();


// every event published anywhere in the workflow now lands there too

GPAL.PublishSimpleEvent(GPALEventType.NOTICE, "Started");

WARNING

Stealth patching edits the browser executable in place to take out automation fingerprints, and copies the original to the same path with .org on the end first. That copy is how the browser goes back to what it was, so it is not a temporary file and removing it is not tidying up. The patch is applied once and later runs recognize it and leave it alone. Nothing else GPAL writes touches an installed program.

On this page

References
Files GPAL Writes to Disk
  • GPAL.yaml - Created and Loaded Automatically
  • Optional Config Files - Load, Save, and Custom Paths
  • Written As A Side Effect Of The Work
    • 💬 Ask GPAL