Core
ForgeBot is healthy
Runtime, business repo access, Slack app path, secrets injection path, and basic toolchain were verified in the source handoff.
ForgeFX internal assistant migration
ForgeBot takes business. AdamoBot stays personal.
The migration is not a rename. It is a clean split of responsibilities: company work moves to ForgeBot; Adam-personal and digital-twin work stays with AdamoBot unless Adam explicitly moves a lane.
Access
Channel coverage needs proof
ForgeBot can only read Slack history where it is already a member. Old files are not proof of live access.
Legacy
Old AdamoBot Slack access is dead
Legacy AdamoBot Slack credential paths should not be revived accidentally or treated as working dependencies.
Executive verdict
ForgeBot can become the company-wide ForgeFX assistant now, but only by using membership-scoped access and keeping Adam-personal context out of scope.
Best next move
Run a read-only Slack coverage audit across the legacy AdamoBot channel contexts, then update local metadata only where live access proves the facts.
Public-safe note
This preview intentionally omits secret values, channel identifiers, private-channel names, customer details, partner-meeting content, and internal credential names.
The full local checklist remains the source for operational execution. This page is a clear decision report, not a credential or access inventory.
Ownership map
ForgeFX staff help
ForgeBot
Repo help, project status, business docs, channel summaries where ForgeBot is a member, operating reports, and routine health.
Adam-personal work
AdamoBot
Personal calendar interpretation, personal email context, Adam digital-twin behavior, and personal task zeroing unless Adam explicitly reassigns the lane.
External actions
Gated
Email sends, public posts, contracts, money movement, client-owned remotes, ticket-closing, and sensitive partner material require explicit approval.
Slack history
Scoped
Recommended model is invite ForgeBot to channels it should serve. Avoid broad user-token search unless Adam deliberately accepts the larger privacy blast radius.
Migration sequence
Approve the boundary rule
One sentence: ForgeBot for ForgeFX business, AdamoBot for Adam-personal.
Audit live Slack coverage
Test the legacy AdamoBot channel contexts read-only and classify each result.
Fix stale metadata
Update local channel docs only when live Slack proof says they are wrong.
Retire dead assumptions
Replace legacy AdamoBot Slack dependencies with ForgeBot membership-scoped access.
Reconcile routines
Compare actual scheduled jobs to old routine folders and migrate only business-owned routines.
Split the old maintenance lane
Separate business operations from Adam-personal Jira, email, calendar, and digital-twin work.
Verify end-to-end
Run selftests, Slack health, optional playground round-trip, channel probes, and scheduled-job checks.
Adam decisions needed
- Should ForgeBot stay membership-scoped for Slack history, or get broad Adam-visible private search?
- Does Adam-personal ticket zeroing remain AdamoBot-only, or move into ForgeBot?
- Is SITREP a personal briefing, a ForgeFX business operating report, or two separate products?
- Which private channels should invite ForgeBot?
- Is live Slack posting outside the playground allowed for final testing?
- Should any email or external-send capability transfer at all?
Success criteria
Staff clarity
ForgeFX staff can ask ForgeBot for business help without thinking about AdamoBot.
Access proof
Every expected business channel has a live readable/not-readable result, not just stale metadata.
No dead dependencies
No active path depends on legacy AdamoBot Slack credentials unless it is explicitly marked historical or blocked.
Routine truth
Active routines are visible in the scheduler, not assumed from folders sitting in the repo.
Boundary intact
Adam-personal, partner, and external-send boundaries remain gated.
Final verification
Selftest, Slack health, channel probes, and scheduled-job checks finish green or report explicit blockers.