/** SDK-owned platform module. This implementation is maintained in goodvibes-sdk. */
/** The two roots every surface derives its storage from. */
export interface GoodVibesHomeOwnership {
    /** The tree root: the directory `.goodvibes/` sits under. */
    readonly homeDirectory: string;
    /** The daemon's own identity directory, under the tree root by default. */
    readonly daemonHomeDirectory: string;
    /**
     * True when either `GOODVIBES_HOME` or `GOODVIBES_DAEMON_HOME` named an
     * override (a blank/whitespace-only value does not count, see
     * resolveGoodVibesHome). Callers that need to know "is this process running
     * out of a relocated tree or identity directory" (e.g. to refuse adopting
     * the machine's real service unit) read this instead of re-reading the raw
     * environment variable themselves, this module is the one reader.
     */
    readonly isOverridden: boolean;
}
/**
 * The tree root for this process.
 *
 * A blank or whitespace-only value is treated as absent rather than as the
 * empty path, because `GOODVIBES_HOME=` in a unit file or a shell wrapper means
 * "unset", and resolving it to `''` would put the whole tree at the filesystem
 * root.
 */
export declare function resolveGoodVibesHome(env?: NodeJS.ProcessEnv): string;
/**
 * The daemon's identity directory.
 *
 * @param homeDirectory - The already-resolved tree root, so a caller cannot
 *   accidentally combine an overridden root with a default daemon home.
 */
export declare function resolveGoodVibesDaemonHome(homeDirectory: string, env?: NodeJS.ProcessEnv): string;
/**
 * The `.goodvibes` directory itself, the tree, not the root it sits under.
 *
 * This exists because the two were being derived independently and did not
 * agree. `GOODVIBES_HOME` meant the tree ROOT to the runtime
 * (`<GOODVIBES_HOME>/.goodvibes/...`) and meant the `.goodvibes` DIRECTORY to
 * the two reporting scripts, which read it as
 * `process.env.GOODVIBES_HOME ?? join(homedir(), '.goodvibes')`. Set it to
 * `/tmp/sandbox` to isolate a run and the runtime wrote
 * `/tmp/sandbox/.goodvibes/`, while a script inspected `/tmp/sandbox` as though
 * it were already the tree, so the two halves of one round disagreed about
 * which files were even in scope.
 *
 * That is the shape of an incident that has already happened here: a
 * home-redirection variable honoured by one entry point and ignored by another
 * put two throwaway credentials in the owner's live secret store. One variable
 * has one meaning now, and it is the runtime's, because the runtime is what
 * writes secrets and because an isolation harness needs a single root that
 * everything falls under.
 *
 * A caller that genuinely wants to name a `.goodvibes` directory directly,
 * auditing a tree that is not under any home, passes it explicitly rather than
 * through the environment. Both scripts keep a `--home` flag for exactly that.
 */
export declare function resolveGoodVibesTreeDirectory(env?: NodeJS.ProcessEnv): string;
/** Both roots at once, what an entry point wants. */
export declare function resolveGoodVibesHomeOwnership(env?: NodeJS.ProcessEnv): GoodVibesHomeOwnership;
/**
 * True when either root was relocated for this process.
 *
 * The daemon lifecycle asks this to decide whether it may adopt the machine's
 * service unit: a process told to run out of somewhere else is a throwaway, and
 * one that adopted the unit had systemd supervise it as the machine's daemon
 * for five hours while it read the real home's credentials.
 *
 * It lives here because the two variables have exactly one reader, and the
 * answer is a question ABOUT them. A caller checking `process.env` for itself is
 * how the second meaning that started all of this gets reintroduced, so the
 * question is answered here rather than asked again somewhere else.
 */
export declare function hasOverriddenGoodVibesHome(env?: NodeJS.ProcessEnv): boolean;
//# sourceMappingURL=goodvibes-home.d.ts.map