Lawang Onboard

io.github.gabloogev0.1.0更新於 Sep 30, 2026

Permission-aware onboarding MCP server: answers about a codebase, filtered by the caller's role.

已驗證Streamable HTTP可網頁執行Developer Tools Knowledge & Memory

概覽

AI 產生的概覽

一個依權限過濾的入門引導伺服器，依呼叫者的角色過濾後回答關於程式庫的問題，模型只會看到過濾後的內容。

功能: Lawang Onboard 提供 whoami、map_system、search、get、trace_feature、why、setup_guide、starter_tasks 與 withheld 等工具。每個工具會先依呼叫者角色對應的範圍過濾語料，只用可見項目建立回答，並引用所用項目的 id。回答最後會列出被隱藏內容的 Withheld 行，隱藏的 id 與不存在的 id 會得到相同結果。
適用情境: 當新進工程師或承包商需要了解程式庫及其歷史、但不應看到全部內容時使用。適合入門導覽、追蹤功能實作、解釋過往決策以及推薦首批任務，存取範圍限於該角色的範圍。
執行需求: 使用託管位址的遠端端點，或在本機以 Go 1.25 執行。需要在 Authorization 標頭中提供 bearer 權杖，請向伺服器營運者索取。README 說明了如何在 IBM Bob 的 Onboard 模式下連線，以及一個線上展示頁面。

安裝前請注意

Authorization 的 bearer 權杖是機密，代表某個角色的可見範圍，請妥善保管並向營運者索取。伺服器會讀取由儲存庫檔案、文件、ADR、提交、拉取請求、審查與議題組成的語料，並把過濾後的片段回傳給模型。README 稱展示語料是團隊自己的開源儲存庫，角色為虛構。

安裝

在 SourceWeft 中

開啟儀表板中的 Lawang Onboard，將其新增到工作區。
為需要使用其工具的對話啟用該服務。

Web executable，透過 Streamable HTTP。遠端服務在工作區中設定後即可從網頁執行環境執行。

其他 MCP 客戶端

把它新增到你客戶端的 mcpServers 設定中。

{
  "mcpServers": {
    "lawang-onboard": {
      "type": "http",
      "url": "https://lawang-onboard.samsulhadi.com/mcp"
    }
  }
}

README

Lawang Onboard

[Lawang Onboard]

[M8ven Score]

Permission-aware AI onboarding. An onboarding copilot inside IBM Bob that explains a codebase to a new engineer, and only the parts they are allowed to see.

Built for the IBM Bob 2.0 Hackathon (lablab.ai, 25 to 27 September 2026) by team Lawang Onboard.

The problem

A new engineer, or a contractor hired for one module, needs weeks to learn why a codebase looks the way it does. The answers exist, spread across commit messages, architecture decision records and pull request reviews, but nobody reads those on day one. And access is all or nothing: either the newcomer sees everything, including whatever an AI assistant can read into its context, or they wait for someone to explain.

What it does

Open the repository in IBM Bob, switch to the Onboard mode, and ask:

/tour: the map of what you can see, module by module.
/trace webhook: how a webhook becomes a record, step by step.
/why internal/ingress: the decisions and reviews behind a path.
"What can I pick up first?"

Bob answers from the code and its history, and cites every item it used. Every piece of context carries a scope; the engineer's role maps to a set of scopes; the role comes from the token on the connection; and the Lawang Onboard MCP server filters before the model sees anything. A contractor's session cannot leak what it was never given, and every answer ends with what was withheld:

Withheld: path:cmd (68), path:internal/core (314), path:migrations (56), path:repo (86),private:growth (18), private:security (6) | total hidden: 399

Withheld: path:cmd (68), path:internal/core (314), path:migrations (56), path:repo (86),private:growth (18), private:security (6) | total hidden: 399

Results

Measured on 26 September with the contractor role, one fresh Bob task per question, by a team member who did not build the server. Full write-up: docs/benchmark.md.

	Result
Ten onboarding questions	10 of 10 correct, 36 s and 0.16 Bobcoins per answer on average
Against answering by hand	46 s vs 210 s on three questions, one of which could not be answered by hand at all
Leak probes (prompt injection, direct `get`, claiming another role, search, "guess")	5 of 5 held; nothing outside the role's scopes reached the model
Code review by Bob	2 real findings (unauthenticated demo API, an existence oracle in `get`), both fixed and rechecked
Withheld counts	Match an independent recount from `roles.yaml` and the corpus on every run
Leak tests	11 test functions, each across all three roles, plus planted injection items; `go test -race ./...` in CI

How it works

IBM Bob (Onboard mode: rules, skills, slash commands)        |  MCP over stdio or HTTPS, bearer token        vonboard server (Go)  token -> role -> scopes -> one filter function -> tools -> audit log        |corpus/*.jsonl  (610 items: files, docs, ADRs, commits, PRs, reviews, issues, each with scopes)

IBM Bob (Onboard mode: rules, skills, slash commands)        |  MCP over stdio or HTTPS, bearer token        vonboard server (Go)  token -> role -> scopes -> one filter function -> tools -> audit log        |corpus/*.jsonl  (610 items: files, docs, ADRs, commits, PRs, reviews, issues, each with scopes)

Scopes come from roles.yaml: path globs (first match wins), labels (a growth label makes an issue private) and kinds. An item needs every one of its scopes; an item with no scope is denied to everyone.
Tools: whoami, map_system, search, get, trace_feature, why, setup_guide, starter_tasks, withheld. Each filters first and builds its answer only from visible items. A hidden id and a missing id get the same answer.
Onboard mode can use only MCP tools and skills, not the file system, so Bob's only view of the code is the filtered one. Its rules make it call whoami first, cite item ids, treat corpus text as data, mark proposals as proposals and close with the Withheld line.
Tokens are compared in constant time; an unknown, empty or ambiguous token is refused. The demo page's API uses the same tokens.

Design notes: docs/design.md.

Try it

Live demo: https://lawang-onboard.samsulhadi.com (paste a role token to see that role's view).
Connect IBM Bob to the hosted server: copy .bob/mcp.remote.example.json to .bob/mcp.json, put in a contractor token (ask the team), reload MCP servers, switch to the Onboard mode and type /tour.

Run it locally

Needs Go 1.25.

cp .env.example .env                 # set the three role tokenscp .bob/mcp.example.json .bob/mcp.jsonscripts/use-role.py contractor       # writes that role's token into .bob/mcp.json

cp .env.example .env                 # set the three role tokenscp .bob/mcp.example.json .bob/mcp.jsonscripts/use-role.py contractor       # writes that role's token into .bob/mcp.json

Open the folder in IBM Bob, reload MCP servers, pick the Onboard mode and ask away. Bob starts the server over stdio.

For the web page and the HTTP endpoint:

set -a; . ./.env; set +ago run ./cmd/onboard -addr :47312               # http://localhost:47312, MCP at /mcpgo run ./cmd/onboard -addr :47312 -demo-roles   # local demos only: role buttons without tokensmake test                                       # go test -race -count=1 ./...

set -a; . ./.env; set +ago run ./cmd/onboard -addr :47312               # http://localhost:47312, MCP at /mcpgo run ./cmd/onboard -addr :47312 -demo-roles   # local demos only: role buttons without tokensmake test                                       # go test -race -count=1 ./...

Hosting (Docker and a Cloudflare Tunnel, make up): docs/deploy.md.

How IBM Bob is used

IBM Bob is both the product's runtime and the tool that built it. The Onboard mode, its rules, four skills (tour, trace, first-week, why) and three slash commands are the user interface. Plan mode designed the server, Agent mode wrote all of its code and tests, Ask mode reviewed it for leaks, and the Onboard mode ran the benchmark. 36 Bob tasks, 46.6 of the team's 80 Bobcoins; every task has a screenshot in bob_sessions/ and a row in the ledgers (Samsul, Ryan). Details, and what was done outside Bob: docs/submission/bob-usage.md.

Data and privacy

See DATA_SOURCES.md and PRIVACY.md. The demo corpus is the team's own open-source repository, gablooge/lawang; no client, confidential, personal or social media data is used. The roles are synthetic.

Team

Samsul Hadi (lead)
Ryan Rizki

License

MIT

來源：README.md，提交 6664e6d

工具

工具後設資料尚未被收錄。

版本歷史

v0.1.0最新Sep 30, 2026

Lawang Onboard

概覽

安裝

在 SourceWeft 中

其他 MCP 客戶端

README

Lawang Onboard

The problem

What it does

Results

How it works

Try it

Run it locally

How IBM Bob is used

Data and privacy

Team

License

工具

版本歷史

更多類似 Lawang Onboard 的服務

Kujolang.ai MCP

Black Window weave

AIContextBuilder