ArcHive
Find the work. Win the work. Run the work.
A capability goes in. Real companies come out, from three independent public sources,
scored with the reasoning shown, screened against the firm's own list, and with a drafted
approach that cites the evidence it came from.
This is the first screen of ArcHive. The rest of the product grows into the same app.
The three sources
| Signal | Where it comes from | What it answers |
|---|
| Filing | SEC EDGAR full-text search | Which companies described this problem in their own words |
| Leadership | SEC 8-K, appointment language | Which just put a new person in the seat that owns it |
| Hiring | Greenhouse and Lever public job boards | Which are staffing up against it right now |
All three are public and unauthenticated. The job boards are documented open endpoints,
boards-api.greenhouse.io and api.lever.co, not scraping.
A company is scored once, with every signal it has, rather than per passage. That is what
makes the stacking claim real: one signal is a guess, three pointing the same way is a
finding, and the scorer says which signals it actually used.
Hiring is corroboration, never discovery. Neither job board can be searched across
companies, so it only ever adds to a company EDGAR already surfaced.
Board tokens are guessed from the company name and verified against the board's own name
before being trusted. When a guess fails, add the real one to BOARD_OVERRIDES in
lib/ats.js. That is cheaper than a cleverer guesser.
The login screen
Set ARCHIVE_PASSWORD to any password and the whole app sits behind a login screen.
Middleware checks every page and every API route, so there is no path in without it.
ARCHIVE_PASSWORD=whatever-you-pick
Signing in sets a signed httpOnly cookie that lasts twelve hours. There is no user
table, because there is one user. The signing key folds in the password itself, so
changing the password signs everyone out immediately.
Leave ARCHIVE_PASSWORD unset and the app is open to anyone with the URL. That is fine
on your own machine and a bad idea anywhere else, so the header shows NO PASSWORD SET in
red whenever the gate is off. Do not deploy with that showing. A crawler finding the URL
can spend your Anthropic credits and query EDGAR under the firm's contact address.
Failed attempts are throttled ten per fifteen minutes per address, and every failure
costs 400ms whether or not the counter is hit. On Vercel the counter is per instance so
the delay is the part that actually holds, which is the honest description of a shared
password: enough to keep a URL private, not enough to protect anything that matters.
Connecting LinkedIn
ArcHive can draft a post or a comment and publish it as you, once you have read it.
It uses the only two LinkedIn products available without a partner application:
- Sign In with LinkedIn, for who you are
- Share on LinkedIn (
w_member_social), to post, comment and like on your own behalf
What no LinkedIn product exposes, at any tier: who engaged with somebody else's post,
connection requests, member-to-member messaging, and profile search. Sales Navigator's
API programme is closed to new partners. So the tools that do those things are not using
an API, and none of it is in here.
Setting up the app, once
-
Go to linkedin.com/developers and create an app.
-
Associate it with the Opportune LinkedIn company page. Whoever administers that
page has to verify the app, which is a link they click. This is the step that needs
someone else, so start it first.
-
Under Products, request Sign In with LinkedIn using OpenID Connect and
Share on LinkedIn. Both are self-serve with a light review rather than a partner
application.
-
Under Auth, add the redirect URLs you will actually use:
http://localhost:3000/api/linkedin/callbackhttps://your-app.vercel.app/api/linkedin/callback
-
Copy the Client ID and Client Secret into three more variables:
| Name | Value |
|---|
LINKEDIN_CLIENT_ID | from the app |
LINKEDIN_CLIENT_SECRET | from the app |
APP_SECRET | any random string, at least 16 characters |
APP_SECRET encrypts the LinkedIn token into an httpOnly cookie. There is no database
and nothing is stored server side, so disconnecting really does remove it.
How it behaves
Nothing publishes on its own. The draft appears in a box you can edit, publishing asks
you to confirm, and the server refuses any publish request that does not carry an
explicit confirmation. The text you see is the text that goes.
Craig's position in the pitch is that a partner's profile is their reputation, so the
system prepares and a person performs. This is that, implemented.
Deploying it
You need a GitHub repo connected to Vercel. Once that is done, every push deploys.
-
Go to vercel.com and sign in with GitHub.
-
Add New, then Project, then import this repository.
-
Framework preset will say Next.js. Leave every build setting alone.
-
Before clicking Deploy, open Environment Variables and add two:
| Name | Value |
|---|
ANTHROPIC_API_KEY | your key from console.anthropic.com |
SEC_USER_AGENT | Opportune LLP ArcHive [email protected] |
ARCHIVE_PASSWORD | the password for the login screen |
Add ARCHIVE_PASSWORD before the first deploy, not after. A public URL without it
is open.
The SEC requires a real contact address in the User-Agent or EDGAR returns 403. Use a
work address, since it identifies the firm to the SEC.
-
Deploy. You get a URL in about a minute.
To change the key later: Settings, Environment Variables, then redeploy.
Running it locally
Optional. You do not need this unless you want to prewarm the cache.
npm install
cp .env.example .env.local # then fill in the two values
npm run dev
Open http://localhost:3000
以上為 README 的開頭部分。其餘內容請閱讀原文。 檢視完整 README ↗
