Commit a3413cf
authored
feat(folders): cut file folders over, and give knowledge bases and tables folders (#6045)
* feat(folders): cut file folders over, and give knowledge bases and tables folders
Builds on the generic resourceType-driven folder engine to finish the migration
and extend it to two more resource trees.
File-folder cutover
- Repoints all 30 `workspace_file_folders` query sites onto `folder` scoped to
`resourceType = 'file'`, id-keyed lookups included — a caller can hand a
workflow folder's id to a file-folder endpoint, and only the predicate stops it
- Adds the missing restore-conflict handling: a file folder whose name was taken
while it was archived now deduplicates against the RESOLVED parent (restore
re-roots when the original parent is still archived) instead of being
permanently unrestorable
- The forking mapper's `resourceType` predicate lives in the `leftJoin`
condition, not the WHERE, where it would silently make the outer join inner
- `servedFolderResourceTypeSchema` gains `file`; the soft-delete sweep enumerates
all four types rather than dropping its predicate
Knowledge Base and Tables folders
- `knowledge_base.folder_id` and `user_table_definitions.folder_id` are now
written and served; both create/move paths admit a folder only through
`findActiveFolder`, scoped to workspace AND resourceType
- Restoring a knowledge base whose folder is still archived re-roots it rather
than filing it somewhere the page never renders; a workspace move re-roots for
the same reason
- Both pages get folder rows, breadcrumbs, inline rename on rows and on the
breadcrumb, move-to submenus, pin/unpin, and drag-a-row-onto-a-folder
Shared folder UI
- One `components/folders/` module now backs Knowledge, Tables, and Files:
`folderBreadcrumbItems` (data for `Resource.Header`, which owns the crumb
chrome), `folderRow`, `folderRowId`/`parseFolderedRowId`, `buildMoveOptions` /
`buildDescendantIndex` / `renderMoveOptions`, `nextUntitledFolderName`,
`FolderContextMenu`, `useFolderNavigation`, `useFolderRowDragDrop`
- Deletes the per-page copies: `files/move-options.tsx` and the Tables-local
folder context menu
Recently Deleted
- Restores folders of every type, not just workflow folders, driven by one
declarative table rather than a branch per resource
Folder pins resolve against `folder` unscoped: file, knowledge-base, and table
folders are all pinnable and all live there, and a folder id addresses exactly
one row.
* fix(folders): close the folder-engine audit findings
Data loss
- Migration 0274 catches up file folders created AFTER 0272. That backfill is guarded
by `WHERE NOT EXISTS (… resource_type = 'file')`, so it fires once; every file folder
created between it and this cutover exists only in `workspace_file_folders`. Without
the catch-up they vanish from Files on deploy and their contents become unreachable
Authorization
- Archived folders were mutable, which bypassed the folder lock: the folder routes and
`updateFolder` filtered id + resourceType but never `deletedAt`, while
`getFolderLockStatus` does — so an archived-but-locked folder reported unlocked. Lock a
subfolder, delete its parent, and any write-level member could rename and reparent it.
PUT and the engine now require an active row; DELETE deliberately still does not, because
it reuses an archived folder's own `deletedAt` to make a partial cascade retryable
- `v1/admin/workflows/import` wrote `folderId` with no validation at all. Migration 0272
dropped the FK, so it accepted a knowledge-base folder, another workspace's folder, or
garbage — and the workflow then rendered under no sidebar node while still executing,
billing, and escaping the folder delete cascade. It now runs the same
`assertFolderInWorkspace` + `assertFolderMutable` pair as `v1/workflows/import`
Restore no longer loses state
- A folder restore ran a bare `archivedAt = null` over its workflows, while the delete had
routed through `archiveWorkflow` — which also disables schedules, webhooks, chats, and MCP
tools. Restoring a folder reported success while every schedule stayed disabled forever
and every chat 404'd. The workflow tree now restores through `restoreWorkflow`, like the
knowledge-base and table trees already did. Deployment state is still deliberately not
revived, matching the single-workflow restore
- Those canonical restores re-root a resource whose folder is archived — correct on its own,
catastrophic inside a cascade, which restores children BEFORE the folder rows and would
therefore dump every child at the workspace root. `resolveRestoredFolderId` takes the
subtree being restored and exempts it. `restoreTable` gained the re-root check it lacked
Correctness
- `getFolderPath` in `lib/folders/tree.ts` walked `parentId` with no `visited` set, so a
cycle in the client cache — reachable through `useReorderFolders`' unchecked optimistic
write — hung the tab. Its twin already had one. Dead `buildFolderMap` deleted
- The sidebar's "New folder" inside a folder hardcoded the name, so the second one 409'd,
was swallowed with only a log line, and the user got no folder and no message. It now
names through the existing `generateSubfolderName` and surfaces failures
- `chunkedBatchDelete` deleted by id with no re-check, so a resource restored between the
SELECT and the DELETE was hard-deleted anyway. Callers now re-assert their soft-delete
predicate on the DELETE
- Recently Deleted and the `restore_resource` tool cover every folder tree, not just
workflow folders, so deleted knowledge-base and table folders are recoverable
Cleanup
- The folder duplicate route stops steering control flow through `throw new Error('literal')`
matched by string, reuses the engine's `nextFolderSortOrder` instead of recomputing it, and
names its workflow scope once
- `servedFolderResourceTypeSchema` documents that its default applies only to an omitted
value; a present-but-unrecognized one is rejected, never coerced to `workflow`
- The `workspace_file_folders` comment described the table as unread and unwritten and
invited a DROP. It was live until this cutover, and it is now the rollback copy — the
comment says so, and names what must be true before anyone drops it
- Pinned rows carry a small non-interactive pin glyph again; they sort to the top and had
nothing explaining why since the inline pin button was removed
Tests
- New `lib/folders/lifecycle.test.ts` covers create/update/delete/restore, the re-root, and
the 23505 mappings; `cleanup-soft-deletes.test.ts` now pins the folder target's
resourceType predicate, which is what keeps the sweep off a not-yet-cut-over type
* improvement(folders): show the pin glyph on Files rows and pin the deploy contract
Files rows were left without the pin indicator the other two lists gained, so a pinned
file or folder still sorted to the top of the Files page with nothing explaining why.
Adds `lib/api/contracts/folders.test.ts`, which pins the three cases that together ARE
the rolling-deploy contract: an omitted `resourceType` defaults to `workflow` (so a client
predating the field keeps working), a present-but-unrecognized one is rejected rather than
coerced, and every served tree is accepted.
* fix(folders): close the findings from the full-diff audit
Migration 0274 reconciles instead of catching up
- The deployed manager writes `workspace_file_folders` EXCLUSIVELY, so `folder`'s file rows
are frozen at the 0272 snapshot: every rename, move, delete, and restore since then lives
only in the legacy table. An insert-only catch-up left all of that diverged — renames
reverted, deleted folders came back as active phantoms, and a stale-active row could hold
the name a newer folder legitimately took
- That last case was silent: the bare `ON CONFLICT DO NOTHING` swallows a NAME violation as
readily as an id one, so the newer folder was discarded and every file inside it stranded.
The conflict target is now `(id)`, so a name collision — which would mean the source
violated its own unique index — fails loudly instead
- Reconciles by parking mirrored names first, then upserting, so no transient state can
collide with the partial unique index. Both statements are idempotent, and the header says
what nothing else would: this has to be run again after the deploy drains, because old pods
keep writing the legacy table until they are gone
`/api/folders` no longer serves file folders
- Adding `'file'` to `servedFolderResourceTypeSchema` opened a second writer over the same
rows. It bypassed the `workspace_file_folders:${workspaceId}` advisory lock that makes the
manager's check-then-write pairs atomic, and it accepted names containing `/`, `\`, `.` and
`..`, which the file surface forbids because a folder name becomes a path segment — a
folder named `a/b` is then unreachable by path forever, and breadcrumbs resolve it as two
segments. The storage cutover never needed a second API, so there isn't one
Conflicts that returned 500
- `v1/admin/workspaces/[id]/import` created its folder with an unserialized SELECT-then-
INSERT, so two imports sharing a folder path failed the whole import. The name is
server-chosen, so it now adopts whichever folder won, like `ensureWorkspaceFileFolderPath`
- Folder duplicate never caught 23505. `newId` is client-supplied, so replaying a duplicate
whose response was lost hit the primary key and returned 500 instead of a 409 the caller
can act on
Performance
- `knowledgeKeys` moved to `hooks/queries/utils/knowledge-keys.ts`. Reading it from
`hooks/queries/kb/knowledge` pulled a ~1000-line hook module — and the `@sim/emcn` barrel
behind it — into `hooks/queries/folders`, which three server prefetches import. That is the
same import edge the navigation-speed audit measured at 11.8MB per workspace route;
`tableKeys` already lived in a keys-only module for exactly this reason
Merge drop
- Knowledge never got the chrome Tables did: its prefetch now fetches the folder tree
alongside the bases, so the list does not paint ungrouped and a `?folderId=` deep link does
not render an empty breadcrumb, and its loading fallback declares the "New folder" action so
the header does not shift on hydration
Comments corrected to match reality
- The shared folder row and context menu claimed Files as a consumer; Files still builds its
own row and routes folders through `FileRowContextMenu`, which the TSDoc now says
- `schema.ts` prescribed a row COUNT comparison before dropping the legacy table. The
divergence 0274 repairs is in row CONTENTS, which a count check passes straight through
* fix(folders): address the review round and the full-PR audit
Reverts the workflow restore hook — it was the wrong fix
- Greptile flagged that restoring a folder leaves schedules disabled and webhooks/chats
inactive. The hook added last round routed workflows through `restoreWorkflow` to address
it, but `restoreDependents` ALREADY clears exactly those columns, in bulk, inside the
restore transaction and matched on the archive timestamp. The hook bought nothing and cost
a per-workflow read/transaction/read OUTSIDE that transaction — roughly 1600 round trips
for a folder of 200 workflows — plus a window where the workflows were active and the
folder was not, and it made `restoreDependents` dead code
- What no restore path can undo is the state archive OVERWRITES: `status: 'disabled'` with
`nextRunAt` cleared, `isActive: false`. Archive does not record what those were, so
restoring them to a constant would re-enable a schedule the user had disabled and re-run a
completed one. Left explicit — redeploy re-activates a schedule — matching deployment state,
which restore also deliberately leaves off. Documented on the config rather than guessed
- Kept the genuine bug the review surfaced underneath it: `restoreWorkflow` un-archived every
dependent by `workflowId` alone, resurrecting a webhook or chat the user had archived days
earlier. Now matched on the workflow's own `archivedAt`, which is the semantics this feature
documents
Bugbot: orphaned knowledge bases vanished from every view
- Knowledge filtered on a raw `folderId === currentFolderId` and never re-rooted a base whose
folder is missing or archived, so a base restored on its own — or left behind by a partial
cascade — was invisible everywhere. Tables already fell those back to the root
A dead `?folderId=` is now healed instead of being a dead end
- A bookmark to a deleted folder rendered the root title over an empty grid, hid everything
actually at the root, and — worse — left every create/upload action targeting the dead id,
filing new resources somewhere nothing could reach. `useFolderNavigation` clears it once the
folder list resolves, which fixes Files, Knowledge, and Tables at once
Parity gaps found by auditing against Files
- Tables sorted folders newest-first on a clean URL while Files and Knowledge sorted A→Z: its
sort params are defaulted, so the raw column was never null. Reads `activeSort` now
- On Tables you could not delete the folder you were standing in — its own row is not in the
list, and the crumb menu offered only Rename, which also made the step-out branch
unreachable dead code
- A failed knowledge-base move was logged and never surfaced, so a rejected move — from the
submenu or from a drag — looked like nothing happened
- A drag begun in another mount of the page could never be dropped: `onDragOver` bailed before
`preventDefault`, so no drop event ever fired and the `dataTransfer` fallback in `onDrop`
was unreachable. External/foreign drags are still ignored, so an OS file dropped on the list
cannot navigate the tab away
Files: a folder cycle crashed the page
- The folder-size roll-up recursed with no `visited` guard, so a parent/child cycle in the
cached tree — reachable through the optimistic folder-move write — recursed until the stack
blew and the page went blank. Also indexes children once instead of re-scanning per node
Migration 0274 is now atomic
- 0272 ends with an embedded COMMIT for its CONCURRENTLY index builds, so this file is not
guaranteed to run inside drizzle's batch transaction. Wrapped in a DO block so the parking
pass cannot commit without the reconcile, which would leave every mirrored folder holding a
placeholder name
- Validated with a read-only dry run: no active name duplicates, no orphaned or
cross-workspace parents, and no id collisions with `workflow_folder`, so the insert cannot
trip the unique index, the FKs, or the resource-type trigger
Smaller corrections
- Knowledge indexed its members for the owner comparator instead of two linear scans per
comparison, and logs a load failure from an effect rather than the render body
- Files uses the shared root sentinel instead of a bare `'__root__'` in two places
- `restore_resource` documents that its two new folder types are unreachable until the enum in
the copilot service's tool catalog — a different repository — widens
- Corrected a forking comment that still described file folders as a separate table
* docs(folders): record the 0272 + 0274 dry-run results on the migration
A read-only dry run materialises the complete post-0272 `folder` table from both source
tables and asserts every constraint it declares: no NULL names, no primary-key collisions
between the two source tables, no unique-index violations, no resource-type or workspace
trigger violations, and no parent/user/workspace FK violations. 0272's dedup renames only
workflow folders, never file folders — the latter is what lets pass 2 write raw names.
* fix(folders): close the findings from the line-by-line audit of the PR
Data integrity
- Workspace fork copied `folderId` verbatim onto the child's tables and knowledge bases. The
column carries no workspace, so a forked row pointed at a folder owned by the SOURCE
workspace — invisible in the fork, and mutated from under it when the source later deleted
that folder (`ON DELETE SET NULL`). Latent until now because nothing wrote a non-null
`folderId` for those two resources; this PR is what makes it reachable. Forked resources land
at the root, like forked files already did
Interaction bugs
- Clearing a dead `?folderId=` wrote through the params' default `history: 'push'`, so Back
returned to the dead URL, which healed and pushed again — the Back button was dead on that
page. It replaces now: opening a folder is navigation, correcting a URL that never pointed
anywhere is not
- That same heal keyed off `isLoading`, which is false for a DISABLED query, false for an
ERRORED one, and false while `keepPreviousData` is showing the previous workspace's folders.
In all three the list is empty or stale, so a transient fetch failure — or a workspace switch
— threw away a perfectly good open folder. Gated on `isSuccess && !isPlaceholderData`
- "New folder" while a search was active created the folder but never showed it: the search
filters folders too, so the new row did not match, the rename field never appeared, and the
create read as a no-op. Both pages clear the search so the thing just created is on screen
- The drag ghost was removed only by `dragend`, which fires on the source row. The table is
virtualized, so scrolling the source out of view mid-drag unmounted it, the event never
arrived, and the ghost stayed on the page with every row stuck at drag opacity. Cleaned up on
unmount as the backstop
- A drag begun in another mount highlighted every folder as a valid target — including the
dragged folder itself — then silently did nothing on drop. It only highlights when the source
is known and was actually checked
Correctness
- The folder-duplicate route caught 23505 across the WHOLE handler, so a unique violation
raised while copying the workflows inside the folder was relabelled "a folder with this name
already exists". Scoped to the folder INSERT, which is the only place the two conflicts the
caller can act on (client-supplied `newId` replay, concurrent name take) actually arise
- The optimistic folder create derived its sort order from the workspace's WORKFLOWS regardless
of resource type. Only the workflow tree interleaves folders and resources in one ordering
space, so a knowledge-base or table folder was placed against an unrelated one
- A table archived between `checkAccess` and the move surfaced as a 500 with a "not found"
body; it is a 404
- `FOLDER_RESOURCE_TYPE_BY_RESTORABLE` was a `Partial` record, so adding a folder tree without a
mapping would compile and silently restore into the workflow tree. Total record now
- Recently Deleted paired query results to folder trees by ARRAY POSITION; reordering the const
would have filed knowledge folders under Tables with no type error. Keyed by type
- The knowledge move's no-op guard compared against the snapshot taken when the menu opened
rather than the live row
Performance — the module split now actually does what it claimed
- `knowledge-keys.ts` justified itself as keeping server prefetches off the ~1000-line
`kb/knowledge` module, but `knowledge/prefetch.ts` still imported its stale-time constant from
exactly that module, whose first line pulls the `@sim/emcn` barrel. Worse, this PR had ADDED
the same class of edge to four prefetches via `FOLDER_LIST_STALE_TIME`/`mapFolder`
- `FOLDER_LIST_STALE_TIME`, `mapFolder`, and `KNOWLEDGE_BASE_LIST_STALE_TIME` now live beside
their key factories, so all four server prefetches import only keys-and-constants modules.
`mapFolder` keeps its explicit field list rather than a spread, so the cached shape cannot
drift from a client fetch
Honesty in comments
- The KB retention `deleteFilter` narrows the restore race but does not close it — documents
hard-deleted by `onBatch` do not come back, so a restore landing mid-batch returns an emptied
base. Said so
- A failed folder restore leaves children active while their folders are still archived. They
are reachable (both lists fall an unresolvable `folderId` back to the root) but they sit at
the root until the restore is retried. Said so
Product policy made visible
- Restore deliberately does not re-enable schedules, webhooks, or chats, because archive
overwrites their state without recording it. A deliberately-disabled schedule or webhook is a
common state rather than an edge case, so reactivating to a constant would be wrong more often
than right. Recently Deleted now says so at the moment of restore instead of leaving it to be
discovered
Smaller
- Pin glyph: dropped the doubled gap, added `role='img'` so the state is announced
- "Move here" carries the folder glyph its sibling leaves do
- `useMoveTable` had stolen `useDeleteTable`'s doc block
- Dead `.returning` column and a `?? null` on a non-nullable param in `moveTableToFolder`
- Tables reads one sort source for both blocks, matching Knowledge
- New test pins that `updateFolder` refuses an archived folder — the guard that stops a delete
from unlocking its locked subfolders
* fix(tables): re-read live placement before skipping a move as a no-op
`handleMoveTable` and `handleMoveFolder` decided "already there, nothing to do" from
`activeTable`/`activeFolder`, which are snapshots taken when the context menu opened. A refetch
or a concurrent move since then makes that comparison stale, so the write the user just asked
for is silently skipped and the row stays where it was. Both now compare against the live list,
matching the knowledge-base move.
* chore(folders): drop production figures from migration and code comments
This repository is public. The 0274 header and the Recently Deleted policy comment carried
concrete counts and ratios taken from the production database, which is operational detail that
does not belong in open source. Both now state the property that matters — what was asserted,
and why disabled-on-restore is the safe default — without the underlying numbers.
* fix(folders): close the findings from auditing the whole release landing unit
Audited as the unit that actually ships — #6014 (pinning), #6025 (workflow folders onto the
generic table), #6037 (the engine) and this branch together against `main`, rather than this
branch against `staging`.
Authorization
- `PUT /api/folders/reorder` still operated on archived folders. `getFolderLockStatus` skips
archived rows, so `assertFolderMutable` there was a guaranteed no-op — meaning a locked folder
became freely reparentable the moment its parent was deleted. This branch closed exactly that
hole on `PUT /api/folders/[id]` and left its sibling open, then widened reorder to three
resource trees. Reordering an archived folder is also wrong on its own terms:
`collectArchivedSubtreeIds` walks the cascade by parent, so moving a branch out of an archived
subtree silently drops it from that folder's restore
Data loss in the purge
- `batchDeleteByWorkspaceAndTimestamp` forwarded its eligibility predicate only into the SELECT,
never the DELETE. The `folder` target runs through it, so a restore committing between the two
statements had its folder hard-deleted anyway — taking the placement of the children the
restore had just brought back. The workflow purge re-checks for precisely this reason and the
knowledge-base sweep gained the same guard earlier in this branch; `folder` had neither. The
wrapper now re-asserts eligibility on the DELETE for every caller
Wire boundary
- `toPinnedItemApi` had no return type, so `pinned_item.resource_type` — plain `text` by design,
against a closed contract enum — was never checked. Annotating it surfaced the real hole
immediately: during a rolling deploy an older pod can read a pin a newer one wrote, and
returning it would fail response validation and take the WHOLE list down rather than the one
row. Unknown kinds are now narrowed out explicitly at the boundary instead of surviving by
accident on a filter whose stated job is something else
Interaction
- The knowledge-base FOLDER move still compared against the snapshot taken when the menu opened.
The resource move on that page and both Tables handlers were fixed earlier in this branch; this
was the last one
Operational
- 0274's "re-run after drain" instruction needed a precondition. Cleanup hard-deletes from
`folder` but never from `workspace_file_folders`, so a re-run after a purge would reinstate
every purged file folder as a soft-deleted phantom whose files are already gone. Retention is
far longer than any drain, so running it promptly is sufficient — but the instruction said
nothing about ordering
Accuracy
- Four comments named symbols that do not exist or no longer apply: `useFolderCreateWithDedup`
(never existed — it is `nextUntitledFolderName`), `collectActiveSubtreeIds`,
`restoreFolderCascade` as the live restore path, and a claim that a server
`createSearchParamsCache` reads the shared folder param. The shared param doc also now admits
Files declares its own `?folderId=` rather than claiming to be the single declaration
- `FOLDER_RESOURCES.file` is unreachable at runtime — `servedFolderResourceTypeSchema` does not
serve `'file'` — and a reader would reasonably assume otherwise. Says so, and says what routing
file folders through the generic engine would bypass
- `pinnedItem.resourceType`'s inline comment was missing `'folder'`
- `folders.test.ts` fixtures still carried `color` and `isExpanded`, both deliberately dropped
from the generic table — pre-consolidation rows masquerading as folders
- `getFolders` in the folder cache had one caller, in its own file
* fix(folders): gate the orphan fallback on a resolved folder index, not a loading flag
The URL heal was fixed to use `isSuccess && !isPlaceholderData`, but the list filters that
decide "this resource's folderId does not resolve, so show it at the root" were left on
`isLoading` — the same footgun, one layer down.
`isLoading` is false for a disabled query (no workspaceId), false for an errored one, and —
because `useFolders` sets `keepPreviousData` — false while the previous workspace's folders are
still on screen during a switch. In all three the index is empty or belongs to another
workspace, so every foldered knowledge base and table was treated as an orphan and dragged to
the root, or filtered out of a deep-linked folder entirely. A transient fetch failure was enough
to make a folder look empty.
`useFolderNavigation` now exposes `foldersResolved` instead of `isLoading`, so the heal and both
list filters share one signal and the footgun is no longer reachable from the hook's surface.1 parent 41a9ae9 commit a3413cf
99 files changed
Lines changed: 23640 additions & 639 deletions
File tree
- apps/sim
- app
- api
- folders
- [id]
- duplicate
- reorder
- knowledge
- [id]
- pinned-items
- table
- [tableId]
- import-async
- import-csv
- v1/admin
- workflows/import
- workspaces/[id]/import
- workspace/[workspaceId]
- components
- folders
- resource
- files
- components
- action-bar
- home
- components/mothership-view/components/resource-registry
- knowledge
- components
- create-base-modal
- hooks
- lib
- settings/components/recently-deleted
- tables
- components
- w
- [workflowId]/components/panel/components/editor/components/sub-block/components/knowledge-base-selector
- components/sidebar/components/workflow-list/components/folder-item
- background
- ee/workspace-forking/lib
- copy
- mapping
- hooks
- kb
- queries
- kb
- utils
- lib
- api/contracts
- knowledge
- cleanup
- copilot/tools/handlers
- folders
- knowledge
- pinned-items
- resources/orchestration
- table
- uploads/contexts/workspace
- workflows
- orchestration
- workspaces
- packages/db
- migrations
- meta
Some content is hidden
Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
3 | 3 | | |
4 | 4 | | |
5 | 5 | | |
| 6 | + | |
6 | 7 | | |
7 | | - | |
| 8 | + | |
8 | 9 | | |
9 | 10 | | |
10 | 11 | | |
11 | 12 | | |
12 | 13 | | |
13 | 14 | | |
14 | 15 | | |
| 16 | + | |
15 | 17 | | |
16 | 18 | | |
17 | 19 | | |
18 | 20 | | |
19 | 21 | | |
20 | 22 | | |
21 | 23 | | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
| 35 | + | |
| 36 | + | |
| 37 | + | |
| 38 | + | |
| 39 | + | |
| 40 | + | |
| 41 | + | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
22 | 48 | | |
23 | 49 | | |
24 | 50 | | |
| |||
46 | 72 | | |
47 | 73 | | |
48 | 74 | | |
49 | | - | |
| 75 | + | |
50 | 76 | | |
51 | 77 | | |
52 | 78 | | |
53 | 79 | | |
54 | 80 | | |
55 | | - | |
| 81 | + | |
56 | 82 | | |
57 | 83 | | |
58 | 84 | | |
| |||
62 | 88 | | |
63 | 89 | | |
64 | 90 | | |
65 | | - | |
| 91 | + | |
| 92 | + | |
| 93 | + | |
| 94 | + | |
| 95 | + | |
66 | 96 | | |
67 | 97 | | |
68 | 98 | | |
69 | 99 | | |
70 | | - | |
| 100 | + | |
71 | 101 | | |
72 | 102 | | |
73 | 103 | | |
| |||
76 | 106 | | |
77 | 107 | | |
78 | 108 | | |
79 | | - | |
80 | | - | |
81 | | - | |
82 | | - | |
83 | | - | |
84 | | - | |
85 | | - | |
86 | | - | |
87 | | - | |
88 | | - | |
89 | | - | |
90 | | - | |
91 | | - | |
92 | | - | |
93 | | - | |
94 | | - | |
95 | | - | |
96 | | - | |
| 109 | + | |
| 110 | + | |
| 111 | + | |
| 112 | + | |
| 113 | + | |
| 114 | + | |
97 | 115 | | |
98 | | - | |
99 | | - | |
100 | | - | |
101 | | - | |
102 | | - | |
103 | | - | |
104 | | - | |
105 | | - | |
106 | | - | |
107 | | - | |
108 | | - | |
109 | | - | |
110 | | - | |
| 116 | + | |
| 117 | + | |
111 | 118 | | |
112 | 119 | | |
113 | 120 | | |
114 | 121 | | |
115 | 122 | | |
116 | | - | |
| 123 | + | |
117 | 124 | | |
118 | 125 | | |
119 | | - | |
120 | | - | |
121 | | - | |
122 | | - | |
123 | | - | |
124 | | - | |
125 | | - | |
126 | | - | |
127 | | - | |
128 | | - | |
129 | | - | |
130 | | - | |
| 126 | + | |
| 127 | + | |
| 128 | + | |
| 129 | + | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
| 136 | + | |
| 137 | + | |
| 138 | + | |
| 139 | + | |
| 140 | + | |
| 141 | + | |
| 142 | + | |
| 143 | + | |
| 144 | + | |
| 145 | + | |
| 146 | + | |
| 147 | + | |
| 148 | + | |
| 149 | + | |
| 150 | + | |
| 151 | + | |
| 152 | + | |
| 153 | + | |
| 154 | + | |
| 155 | + | |
| 156 | + | |
| 157 | + | |
131 | 158 | | |
132 | 159 | | |
133 | 160 | | |
| |||
183 | 210 | | |
184 | 211 | | |
185 | 212 | | |
186 | | - | |
| 213 | + | |
| 214 | + | |
| 215 | + | |
187 | 216 | | |
188 | 217 | | |
189 | 218 | | |
190 | 219 | | |
191 | | - | |
192 | | - | |
193 | | - | |
194 | | - | |
195 | | - | |
196 | | - | |
197 | | - | |
198 | | - | |
199 | | - | |
200 | | - | |
201 | | - | |
202 | | - | |
203 | | - | |
204 | | - | |
205 | | - | |
206 | | - | |
207 | | - | |
208 | | - | |
209 | | - | |
210 | | - | |
211 | | - | |
212 | | - | |
213 | | - | |
| 220 | + | |
| 221 | + | |
| 222 | + | |
214 | 223 | | |
215 | | - | |
216 | | - | |
217 | | - | |
218 | | - | |
219 | | - | |
220 | | - | |
| 224 | + | |
| 225 | + | |
| 226 | + | |
| 227 | + | |
| 228 | + | |
| 229 | + | |
221 | 230 | | |
222 | 231 | | |
223 | 232 | | |
| |||
250 | 259 | | |
251 | 260 | | |
252 | 261 | | |
253 | | - | |
| 262 | + | |
| 263 | + | |
| 264 | + | |
254 | 265 | | |
255 | 266 | | |
256 | 267 | | |
257 | | - | |
| 268 | + | |
258 | 269 | | |
259 | 270 | | |
260 | | - | |
| 271 | + | |
| 272 | + | |
| 273 | + | |
| 274 | + | |
261 | 275 | | |
262 | 276 | | |
263 | 277 | | |
| |||
284 | 298 | | |
285 | 299 | | |
286 | 300 | | |
287 | | - | |
| 301 | + | |
288 | 302 | | |
289 | 303 | | |
290 | 304 | | |
| |||
295 | 309 | | |
296 | 310 | | |
297 | 311 | | |
298 | | - | |
| 312 | + | |
299 | 313 | | |
300 | 314 | | |
301 | 315 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2 | 2 | | |
3 | 3 | | |
4 | 4 | | |
5 | | - | |
| 5 | + | |
6 | 6 | | |
7 | 7 | | |
8 | 8 | | |
| |||
45 | 45 | | |
46 | 46 | | |
47 | 47 | | |
| 48 | + | |
| 49 | + | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
| 53 | + | |
48 | 54 | | |
49 | 55 | | |
50 | 56 | | |
51 | | - | |
| 57 | + | |
| 58 | + | |
| 59 | + | |
| 60 | + | |
| 61 | + | |
| 62 | + | |
| 63 | + | |
52 | 64 | | |
53 | 65 | | |
54 | 66 | | |
| |||
143 | 155 | | |
144 | 156 | | |
145 | 157 | | |
| 158 | + | |
| 159 | + | |
| 160 | + | |
| 161 | + | |
| 162 | + | |
| 163 | + | |
146 | 164 | | |
147 | 165 | | |
148 | 166 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
3 | 3 | | |
4 | 4 | | |
5 | 5 | | |
6 | | - | |
| 6 | + | |
7 | 7 | | |
8 | 8 | | |
9 | 9 | | |
| |||
38 | 38 | | |
39 | 39 | | |
40 | 40 | | |
| 41 | + | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
| 48 | + | |
41 | 49 | | |
42 | 50 | | |
43 | 51 | | |
44 | | - | |
| 52 | + | |
| 53 | + | |
| 54 | + | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
| 58 | + | |
45 | 59 | | |
46 | 60 | | |
47 | 61 | | |
| |||
138 | 152 | | |
139 | 153 | | |
140 | 154 | | |
141 | | - | |
| 155 | + | |
| 156 | + | |
| 157 | + | |
| 158 | + | |
| 159 | + | |
| 160 | + | |
| 161 | + | |
142 | 162 | | |
143 | 163 | | |
144 | 164 | | |
| |||
0 commit comments